From owner-freebsd-stable@freebsd.org Sun Apr 30 12:07:01 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ACA9D55189 for ; Sun, 30 Apr 2017 12:07:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 217551331; Sun, 30 Apr 2017 12:07:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v3UC6RJ9039382 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 30 Apr 2017 15:06:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v3UC6RJ9039382 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v3UC6QCn039380; Sun, 30 Apr 2017 15:06:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Apr 2017 15:06:26 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Gerald Pfeifer , freebsd-stable@freebsd.org, Jung-uk Kim , papowell@astart.com Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Message-ID: <20170430120626.GT1622@kib.kiev.ua> References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 12:07:01 -0000 On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: > On 29 Apr 2017, at 19:00, Gerald Pfeifer wrote: > > > > On Thu, 27 Apr 2017, Jung-uk Kim wrote: > >>>>>>> I found the problem, but I do not know how to resolve this. When you > >>>>>>> install the GCC compiler from the PKG repository it appears to create a > >>>>>>> modified set of include files from the system (default?) include files > >>>>>>> (/usr/include). However, when the modified /usr/include/sys/types.h > >>>>>>> file is created, the typedef for vm_ooffset_t is modified, and there is > >>>>>>> no reference to __vm_ooffset_t that the compiler can resolve. > >>>>>>> > >>>>>>> < typedef __int64_t vm_ooffset_t; > >>>>>>> --- > >>>>>>>> typedef __vm_ooffset_t vm_ooffset_t; > >>>>>> ... > >>>>>> You have to rebuild lang/gcc from the ports tree to fix this problem. > >>>>>> > >>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html > >>>>> Does this mean that the GCC port/package needs to be updated? If so, > >>>>> should I file a PR report on this issue? > >>>>> I (temporarily) fixed this problem by hand editting the modified types.h > >>>>> file and things seem to work. > >>>> I already wrote a patch (attached). :-) > >> If the maintainer (gerald) approves. CC'd. > > > > Thanks for bringing this to my attention. > > > > Can you please help me understand why this is necessary? > > This is because gcc's fixincludes process makes copies of certain system > headers (in this case, /usr/include/sys/types.h) with slight > modifications. Then, it places the directory containing the modified > headers at the front of the include search path. So far so good. > > Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t > change, the header in gcc's own preferred directory might not match the > definitions which are expected, leading to compilation errors. > > > > If the > > port/package is builts from scratch, does this trigger the problem? > > Yes, basically you need to rebuild all gcc ports from scratch, whenever > you update any system header that matches gcc's list of files it wants > to modify. > > But getting those errors in the first place can be very confusing to an > end-user. And having to rebuild all those ports might be a burden. > > As some people pointed out, simply moving away or deleting the directory > with fixed includes appears to work around the problems. So maybe the > question is if gcc really needs to modify those headers at all? > > I have looked at gcc's build system a bit, but it does not seem very > easy to disable the fixincludes step. I guess that is simply not > supported. > > So in that case, if Jung-uk's solution works, it is probably the best > way forward, and it can even be upstreamed. Jung-uk, how does your > patch handle an updated header under /usr/include which contains e.g. > new definitions, which are not in the fixed includes directory? Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with explicit int64_t and uint64_t use, as the course of action for gcc fixincludes step ? If yes, I completely disagree. The change blocks any future changes to the type that might occur in the base system, for the code compiled by gcc. End result might be as bad as mismatched ABI, in the worst case. I share the opinion that fixincludes is not only useless, but really damaging. Gcc ships workarounds for e.g. issues in X11 headers, which application depends on the presence of the corresponding headers at the gcc build time. For clean (poudriere-like) builds these fixes are never applied, so port build results are inconsistent, at least. Nobody so far explained why fixincludes is needed for the modern base headers. IMO if we have real problems in headers we ship, we must fix it in the base. With all of the above, IMO most sane way to fix problems is to rename fixincludes directory to some name which is ignored by gcc, e.g. include-fixed -> include-fixed.saved. This can be done as post-installation step in the ports. From owner-freebsd-stable@freebsd.org Sun Apr 30 13:12:47 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 077DBD56CBB for ; Sun, 30 Apr 2017 13:12:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD86B8A2; Sun, 30 Apr 2017 13:12:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::87:38f2:5f9b:cc2c] (unknown [IPv6:2001:470:7a58:0:87:38f2:5f9b:cc2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6D4D22572F; Sun, 30 Apr 2017 15:12:42 +0200 (CEST) From: Dimitry Andric Message-Id: <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EDAEE4AB-3DAC-49DC-9764-8FD06F883F44"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Date: Sun, 30 Apr 2017 15:12:27 +0200 In-Reply-To: <20170430120626.GT1622@kib.kiev.ua> Cc: Gerald Pfeifer , freebsd-stable@freebsd.org, Jung-uk Kim , papowell@astart.com To: Konstantin Belousov References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 13:12:47 -0000 --Apple-Mail=_EDAEE4AB-3DAC-49DC-9764-8FD06F883F44 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 30 Apr 2017, at 14:06, Konstantin Belousov wrote: > > On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: ... >> So in that case, if Jung-uk's solution works, it is probably the best >> way forward, and it can even be upstreamed. Jung-uk, how does your >> patch handle an updated header under /usr/include which contains e.g. >> new definitions, which are not in the fixed includes directory? > > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. > > I share the opinion that fixincludes is not only useless, but really > damaging. Gcc ships workarounds for e.g. issues in X11 headers, which > application depends on the presence of the corresponding headers at the > gcc build time. For clean (poudriere-like) builds these fixes are never > applied, so port build results are inconsistent, at least. > > Nobody so far explained why fixincludes is needed for the modern base > headers. IMO if we have real problems in headers we ship, we must fix it > in the base. > > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. I agree, it would be best to avoid storing any copies of system headers completely. Maybe the port can have an option FIX_INCLUDES, which defaults to off? I am not sure if there is anybody that really wants these 'fixed' headers, though. :) -Dimitry --Apple-Mail=_EDAEE4AB-3DAC-49DC-9764-8FD06F883F44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkF4soACgkQsF6jCi4glqNLGwCgkSnnAjlhbDdxePmfPYS32fEZ SgYAnAsubs/QQa1XDkreM0FbWfi9JtQg =wdyW -----END PGP SIGNATURE----- --Apple-Mail=_EDAEE4AB-3DAC-49DC-9764-8FD06F883F44-- From owner-freebsd-stable@freebsd.org Sun Apr 30 15:20:35 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C556D57249 for ; Sun, 30 Apr 2017 15:20:35 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37E2CDAB; Sun, 30 Apr 2017 15:20:34 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from anthias (vie-188-118-250-006.dsl.sil.at [188.118.250.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id DCC2A3F53E; Sun, 30 Apr 2017 11:20:31 -0400 (EDT) Date: Sun, 30 Apr 2017 17:20:27 +0200 (CEST) From: Gerald Pfeifer To: Dimitry Andric , Konstantin Belousov cc: Jung-uk Kim , freebsd-stable@freebsd.org, papowell@astart.com Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition In-Reply-To: <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> Message-ID: References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua> <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 15:20:35 -0000 On Sat, 29 Apr 2017, Dimitry Andric wrote: > This is because gcc's fixincludes process makes copies of certain system > headers (in this case, /usr/include/sys/types.h) with slight > modifications. Then, it places the directory containing the modified > headers at the front of the include search path. So far so good. > > Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t > change, the header in gcc's own preferred directory might not match the > definitions which are expected, leading to compilation errors. >> If the port/package is builts from scratch, does this trigger the >> problem? > Yes, basically you need to rebuild all gcc ports from scratch, whenever > you update any system header that matches gcc's list of files it wants > to modify. That, or run the fixinc.sh script in ./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh. The proposed patch would help with that, but still require a manual run, hence my original question. On Sun, 30 Apr 2017, Konstantin Belousov wrote: > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Okay, thanks for your feedback. > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. This is what I figured, too, and plan on giving a try. It probably warrants an -exp run to be on the safe side. On Sun, 30 Apr 2017, Dimitry Andric wrote: > I agree, it would be best to avoid storing any copies of system headers > completely. > > Maybe the port can have an option FIX_INCLUDES, which defaults to off? > I am not sure if there is anybody that really wants these 'fixed' > headers, though. :) There are two infrastructure improvements for the (current) GCC ports (orthogonal to a few simpler things I've been simplifying today in older ports) that I'd like to conclude first, otherwise there'll be too many balls in the air. ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475 is the last hold-off on the first of them, in case anyone can give this a try. ;-) It is on my list to pursue directly afterwards, then. (Luckily this only hits with most -CURRENT versions of FreeBSD and older packages only.) Gerald From owner-freebsd-stable@freebsd.org Mon May 1 08:17:40 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0290D58E41 for ; Mon, 1 May 2017 08:17:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FE1519C9 for ; Mon, 1 May 2017 08:17:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31330 invoked from network); 1 May 2017 08:17:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 May 2017 08:17:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 01 May 2017 04:17:33 -0400 (EDT) Received: (qmail 25477 invoked from network); 1 May 2017 08:17:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 May 2017 08:17:33 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A6F16EC771C; Mon, 1 May 2017 01:17:32 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Message-Id: <0630A9BC-429E-49F2-B0A0-2313A925B0B4@dsl-only.net> Date: Mon, 1 May 2017 01:17:31 -0700 Cc: dim@FreeBSD.org, Konstantin Belousov To: Gerald Pfeifer , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 08:17:40 -0000 Gerald Pfeifer gerald at pfeifer.com wrote on Sun Apr 30 15:20:35 UTC 2017 : > That, or run the fixinc.sh script in > ./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh. fixinc.sh is designed to be run by (for the */* involved): bootstrap/libexec/gcc/*/*/install-tools/mkheaders and that mkheaders does more than just fixinc.sh as far as changing headers goes, such as limits.h and gsyslmits.h and syslimits.h . In more detail: The mkheaders core loop looks 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 Note that mkheaders also provides various definitions to fixinc.sh, such as MACRO_LIST . Direct use of fixinc.sh likely requires providing appropriate alternate definitions for such. 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). This still leaves the limits.h and gsystemlimits.h and syslimits.h code in place but does block most of the activity. === Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon May 1 09:53:28 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2466D58216 for ; Mon, 1 May 2017 09:53:28 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4598A5D; Mon, 1 May 2017 09:53:28 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from anthias (vie-188-118-250-006.dsl.sil.at [188.118.250.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 8959F3F53E; Mon, 1 May 2017 05:53:26 -0400 (EDT) Date: Mon, 1 May 2017 11:53:24 +0200 (CEST) From: Gerald Pfeifer To: Mark Millard cc: freebsd-stable@freebsd.org, Dimitry Andric , Konstantin Belousov Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition In-Reply-To: <0630A9BC-429E-49F2-B0A0-2313A925B0B4@dsl-only.net> Message-ID: References: <0630A9BC-429E-49F2-B0A0-2313A925B0B4@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 09:53:28 -0000 On Mon, 1 May 2017, Mark Millard wrote: > and that mkheaders does more than just fixinc.sh > as far as changing headers goes, such as limits.h > and gsyslmits.h and syslimits.h . That's a good point, and I guess the *limits.h files do make sense to come from the compiler itself? > 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) : > This still leaves the limits.h and gsystemlimits.h and > syslimits.h code in place but does block most of the > activity. Thanks for this pointer, Mark! I have earmarked this as the first approach to give a try soon, instead of completely yanking the fixincluded directory. Gerald From owner-freebsd-stable@freebsd.org Mon May 1 10:09:02 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CACCD58D62 for ; Mon, 1 May 2017 10:09:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9612BA; Mon, 1 May 2017 10:09:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-213-253.dyn.iinet.net.au [106.68.213.253]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v41A8k9v071992 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 May 2017 03:08:50 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition To: Gerald Pfeifer , Mark Millard References: <0630A9BC-429E-49F2-B0A0-2313A925B0B4@dsl-only.net> Cc: Konstantin Belousov , Dimitry Andric , freebsd-stable@freebsd.org From: Julian Elischer Message-ID: <99fd1a32-f22b-b3a0-1b07-83056239571a@freebsd.org> Date: Mon, 1 May 2017 18:08:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 10:09:02 -0000 On 1/5/17 5:53 pm, Gerald Pfeifer wrote: > On Mon, 1 May 2017, Mark Millard wrote: >> and that mkheaders does more than just fixinc.sh >> as far as changing headers goes, such as limits.h >> and gsyslmits.h and syslimits.h . > That's a good point, and I guess the *limits.h files do make > sense to come from the compiler itself? > >> 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) > : >> This still leaves the limits.h and gsystemlimits.h and >> syslimits.h code in place but does block most of the >> activity. > Thanks for this pointer, Mark! I have earmarked this as the first > approach to give a try soon, instead of completely yanking the > fixincluded directory. since you know the output of the change can you not make the execution dependent on some marker in the files you can test? > > Gerald > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Mon May 1 16:56:51 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B6EAD5920A for ; Mon, 1 May 2017 16:56:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by mx1.freebsd.org (Postfix) with ESMTP id 0B327EE6; Mon, 1 May 2017 16:56:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition To: Konstantin Belousov , Dimitry Andric Cc: Gerald Pfeifer , freebsd-stable@freebsd.org, papowell@astart.com References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua> From: Jung-uk Kim Message-ID: <88ad5747-46df-d688-7acc-56123c5e3f7b@FreeBSD.org> Date: Mon, 1 May 2017 12:56:41 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170430120626.GT1622@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nKEdxnc5e3a19k82imqoflUBqEH0BpiRl" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 16:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl Content-Type: multipart/mixed; boundary="utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r"; protected-headers="v1" From: Jung-uk Kim To: Konstantin Belousov , Dimitry Andric Cc: Gerald Pfeifer , freebsd-stable@freebsd.org, papowell@astart.com Message-ID: <88ad5747-46df-d688-7acc-56123c5e3f7b@FreeBSD.org> Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua> In-Reply-To: <20170430120626.GT1622@kib.kiev.ua> --utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/30/2017 08:06, Konstantin Belousov wrote: > On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote: >> On 29 Apr 2017, at 19:00, Gerald Pfeifer wrote: >>> >>> On Thu, 27 Apr 2017, Jung-uk Kim wrote: >>>>>>>>> I found the problem, but I do not know how to resolve this. W= hen you >>>>>>>>> install the GCC compiler from the PKG repository it appears to = create a >>>>>>>>> modified set of include files from the system (default?) includ= e files >>>>>>>>> (/usr/include). However, when the modified /usr/include/sys/ty= pes.h >>>>>>>>> file is created, the typedef for vm_ooffset_t is modified, and= there is >>>>>>>>> no reference to __vm_ooffset_t that the compiler can resolve. >>>>>>>>> >>>>>>>>> < typedef __int64_t vm_ooffset_t; >>>>>>>>> --- >>>>>>>>>> typedef __vm_ooffset_t vm_ooffset_t; >>>>>>>> ... >>>>>>>> You have to rebuild lang/gcc from the ports tree to fix this pro= blem. >>>>>>>> >>>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2017-Februar= y/064937.html >>>>>>> Does this mean that the GCC port/package needs to be updated? If= so, >>>>>>> should I file a PR report on this issue? >>>>>>> I (temporarily) fixed this problem by hand editting the modified = types.h >>>>>>> file and things seem to work. >>>>>> I already wrote a patch (attached). :-) >>>> If the maintainer (gerald) approves. CC'd. >>> >>> Thanks for bringing this to my attention. >>> >>> Can you please help me understand why this is necessary? >> >> This is because gcc's fixincludes process makes copies of certain syst= em >> headers (in this case, /usr/include/sys/types.h) with slight >> modifications. Then, it places the directory containing the modified >> headers at the front of the include search path. So far so good. >> >> Now, whenever sys/types.h is updated, as happened with the vm_ooffset_= t >> change, the header in gcc's own preferred directory might not match th= e >> definitions which are expected, leading to compilation errors. >> >> >>> If the >>> port/package is builts from scratch, does this trigger the problem? >> >> Yes, basically you need to rebuild all gcc ports from scratch, wheneve= r >> you update any system header that matches gcc's list of files it wants= >> to modify. >> >> But getting those errors in the first place can be very confusing to a= n >> end-user. And having to rebuild all those ports might be a burden. >> >> As some people pointed out, simply moving away or deleting the directo= ry >> with fixed includes appears to work around the problems. So maybe the= >> question is if gcc really needs to modify those headers at all? >> >> I have looked at gcc's build system a bit, but it does not seem very >> easy to disable the fixincludes step. I guess that is simply not >> supported. >> >> So in that case, if Jung-uk's solution works, it is probably the best >> way forward, and it can even be upstreamed. Jung-uk, how does your >> patch handle an updated header under /usr/include which contains e.g. >> new definitions, which are not in the fixed includes directory? >=20 > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. >=20 > The change blocks any future changes to the type that might occur in th= e > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Good point. > I share the opinion that fixincludes is not only useless, but really > damaging. Gcc ships workarounds for e.g. issues in X11 headers, which > application depends on the presence of the corresponding headers at the= > gcc build time. For clean (poudriere-like) builds these fixes are neve= r > applied, so port build results are inconsistent, at least. >=20 > Nobody so far explained why fixincludes is needed for the modern base > headers. IMO if we have real problems in headers we ship, we must fix i= t > in the base. >=20 > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. Agreed. Jung-uk Kim --utu27qcBmOGHBuxOR5ahlSO5M5ELn8P4r-- --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlkHaNEACgkQfJ+WJvzb 8UYLtwf+IOAnQR8b1tY4DbBYmsv57rNdJTFtS6s18cI5fNbYUMyLCHET3uxQ+BhB MAEjopMoCyUiF/YAipGPPt83kcou4td7rb6/0nY63JUPfpoSu+6WQaBLKjiVdNeh NmRBMnsKBXhLYzH6NueVJi2RbptGiWysDzqFubHH2yljspcGtcGYsIYV1CL1k3v+ B3WxpgVPs6PLuxsYAUHtVdvAcaw3H3KnFU+dIGl/M3WU+Umi2+GEsvNrm1XCE01L wVyjqiLsu9JphvUXUQR2xtJg4nbGkSoMNBXJ6pdWMVxe9620yggMbhQgzxR8M57t WQlLfflaMuqpaNY6R3aupNqiDfxPJA== =fgAq -----END PGP SIGNATURE----- --nKEdxnc5e3a19k82imqoflUBqEH0BpiRl-- From owner-freebsd-stable@freebsd.org Tue May 2 03:32:22 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD437D5A332 for ; Tue, 2 May 2017 03:32:22 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 960E28D4 for ; Tue, 2 May 2017 03:32:22 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qt0-x235.google.com with SMTP id m36so102458808qtb.0 for ; Mon, 01 May 2017 20:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=IdxjqPyYlDdl8LKBSW3IxIE39eaSSnGhytWuVxS+hxo=; b=2QTyL34tpNd1D4CaGgaw855SXaEu5cAc8KgFyAiI+KfCuWDcaxAGq8r74iQOZ5W5Qk a0FI63TQzgKUzV6j7ay3uopk/4JcPBqLaItDNIPP0Ho03z7ZCk0S7o1/uRc1L+FLMnd9 +TMDHHT+c23pfD+JJv2dugeMjPZSXIAMayLEBDnVixMG1NpLKgazpqc+fVYfF6zpjGBI 3sXeqxq/6ZgxKI5wishNmoVkbeD+lbDy/bZVMn/sChQOOC9SjJQLMe1R4jNerCFyQ+ob Mh9DTo3Ex+c1uBnPwAlu/0b1dvKHlLK2rW2Nszu0FmEZ7a7HiEWBazJep7fxQ7/Ldxf8 QQAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IdxjqPyYlDdl8LKBSW3IxIE39eaSSnGhytWuVxS+hxo=; b=ZIbsZAyYUSHf0682S/UpzBHiVXxk6y9z+4vyPB9ZzZ/Mka/PQDIaEV1rAoeR8yMkzy 6lr7KnF6kdRAVlusoleecguhHqk426thr0DvCjK/g1oH4f2dg7OaIdHh9g5jVC5KhUU+ H8+Qd77S3sWALBsCPlbPH7oTVYQesWiYlzL/NGqXjpmuRcVMUcyFH0jr5QhjWtbgPPd6 X5NoGm3uvSn/p43Pt+9OcKBln7nb+OgEQ9IVAv+G+Sq4XVVazERvvT9gQ2rq8prj97EG uNQb7hjMv3MUkGCyGq5KI5Z1iv1yx0TKQ4rU5BvR2FQ/zuhPcWc5BVDkGYzH1w/fEUZX vVJQ== X-Gm-Message-State: AN3rC/5IP/7lePmQttch16cACVYY4EdiL/BJ3ki5L0H/Y5ao7qRTJuqz d0qDLduXmUvxNjQxfA9WIL5CKdOd6U6L X-Received: by 10.200.57.18 with SMTP id s18mr23881154qtb.1.1493695941111; Mon, 01 May 2017 20:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.102 with HTTP; Mon, 1 May 2017 20:32:20 -0700 (PDT) X-Originating-IP: [203.99.129.1] From: Jonathan Chen Date: Tue, 2 May 2017 15:32:20 +1200 Message-ID: Subject: STABLE-11 make buildworld as non-root To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 03:32:22 -0000 Hi, I recently updated to STABLE-11/amd64, r317665, and decided to see if I could do a buildworld as a normal user (with a public /usr/obj). Unfortunately, the "make buildworld" stopped with ... ===> lib/libedit (cleandir) rm -f common.h editline.c emacs.h fcns.c fcns.h help.c help.h vi.h tokenizern.c historyn.c editline.o tokenizer.o history.o readline.o tokenizern.o historyn.o editline.po tokenizer.po history.po readline.po tokenizern.po historyn.po editline.pico tokenizer.pico history.pico readline.pico tokenizern.pico historyn.pico libedit.so libedit.so.7.full libedit.so.7.debug libedit.a libedit_p.a libedit.so.7 editline.3.gz editrc.5.gz editline.3.cat.gz editrc.5.cat.gz rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS ===> lib/libedit/edit/readline (cleandir) rm -f .depend .depend.* ===> lib/libelftc (cleandir) rm -f elftc_bfdtarget.o elftc_copyfile.o elftc_demangle.o elftc_reloc_type_str.o elftc_set_timestamps.o elftc_string_table.o elftc_timestamp.o elftc_version.o libelftc_bfdtarget.o libelftc_dem_arm.o libelftc_dem_gnu2.o libelftc_dem_gnu3.o libelftc_hash.o libelftc_vstr.o libelftc.a elftc.3.gz elftc_bfd_find_target.3.gz elftc_copyfile.3.gz elftc_demangle.3.gz elftc_reloc_type_str.3.gz elftc_set_timestamps.3.gz elftc_timestamp.3.gz elftc_string_table_create.3.gz elftc_version.3.gz elftc.3.cat.gz elftc_bfd_find_target.3.cat.gz elftc_copyfile.3.cat.gz elftc_demangle.3.cat.gz elftc_reloc_type_str.3.cat.gz elftc_set_timestamps.3.cat.gz elftc_timestamp.3.cat.gz elftc_string_table_create.3.cat.gz elftc_version.3.cat.gz rm -rf sys rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS ===> lib/libevent (cleandir) rm -f buffer.o evbuffer.o event.o kqueue.o log.o poll.o select.o signal.o buffer.po evbuffer.po event.po kqueue.po log.po poll.po select.po signal.po buffer.pico evbuffer.pico event.pico kqueue.pico log.pico poll.pico select.pico signal.pico libprivateevent.so libprivateevent.so.1.full libprivateevent.so.1.debug libprivateevent.a libprivateevent_p.a libprivateevent.so.1 rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS ===> lib/libexecinfo (cleandir) rm -f backtrace.o symtab.o unwind.o backtrace.po symtab.po unwind.po backtrace.pico symtab.pico unwind.pico libexecinfo.so libexecinfo.so.1.full libexecinfo.so.1.debug libexecinfo.a libexecinfo_p.a libexecinfo.so.1 backtrace.3.gz backtrace.3.cat.gz rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS ===> lib/libexpat (cleandir) rm -f bsdxml.h bsdxml_external.h xmlparse.o xmlrole.o xmltok.o xmlparse.po xmlrole.po xmltok.po xmlparse.pico xmlrole.pico xmltok.pico libbsdxml.so libbsdxml.so.4.full libbsdxml.so.4.debug libbsdxml.a libbsdxml_p.a libbsdxml.so.4 libbsdxml.3.gz libbsdxml.3.cat.gz rm: bsdxml.h: Permission denied rm: bsdxml_external.h: Permission denied *** Error code 1 Stop. make[4]: stopped in /usr/src/lib/libexpat *** Error code 1 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src The "rm -f bsdxml.h bsdxml_external.h ..." looks dodgy to me. Why have these 2 files in the source tree if it's going to be removed early in the build? Cheers. -- Jonathan Chen From owner-freebsd-stable@freebsd.org Tue May 2 13:07:48 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 209A9D5AAE2 for ; Tue, 2 May 2017 13:07:48 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA81AE3D for ; Tue, 2 May 2017 13:07:47 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 5AEF745FF0 for ; Tue, 2 May 2017 15:07:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1493730456; bh=7QKlsPEHoH2c0tSYZXCdciWkeWE82RC1p AZu5h5W1Nw=; b=ozkbLICiQ8kfALZJKdvaAJOIes86Q7w7Z1VEle8C1ridmQXD1 lY2pynRgW9DrAnv/AMcp1OITLlHAw0woC+kxV4KlpfuEKZsr3MTWebbqYo0hRJR4 kiKGTMxxGCoOc6FH7g0OEhwg5y77jqUpevfcz0p+wCuAeQaa4kPDpU4uUW5Y0fQx UILSUzdONnt/x0UGKyjlGRIfQoWNI51POayft/VYrlVdEp7GDHLJEOVgHUuErPYc sDMxECPYgtSSVxIs3QU0EJI1p9SyAMZdSssvWgTKtkKlMrFWdKgqfNFsOT3wA+0d btm0KWOjLH40lmYXlxM+Ss1c/OqIGrlRE3GWg== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id WQWGJTz2Pfef for ; Tue, 2 May 2017 15:07:36 +0200 (CEST) Date: Tue, 02 May 2017 15:07:36 +0200 Message-ID: <86lgqfwgo7.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: freebsd-stable@freebsd.org Subject: Re: STABLE-11 make buildworld as non-root In-Reply-To: References: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:07:48 -0000 Jonathan Chen skrev: > > Hi, > I recently updated to STABLE-11/amd64, r317665, and decided to see if > I could do a buildworld as a normal user (with a public /usr/obj). > Unfortunately, the "make buildworld" stopped with > > ... > ===> lib/libedit (cleandir) > rm -f common.h editline.c emacs.h fcns.c fcns.h help.c help.h vi.h > tokenizern.c historyn.c editline.o tokenizer.o history.o readline.o > tokenizern.o historyn.o editline.po tokenizer.po history.po > readline.po tokenizern.po historyn.po editline.pico tokenizer.pico > history.pico readline.pico tokenizern.pico historyn.pico libedit.so > libedit.so.7.full libedit.so.7.debug libedit.a libedit_p.a > libedit.so.7 editline.3.gz editrc.5.gz editline.3.cat.gz > editrc.5.cat.gz > rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS > ===> lib/libedit/edit/readline (cleandir) > rm -f .depend .depend.* > ===> lib/libelftc (cleandir) > rm -f elftc_bfdtarget.o elftc_copyfile.o elftc_demangle.o > elftc_reloc_type_str.o elftc_set_timestamps.o elftc_string_table.o > elftc_timestamp.o elftc_version.o libelftc_bfdtarget.o > libelftc_dem_arm.o libelftc_dem_gnu2.o libelftc_dem_gnu3.o > libelftc_hash.o libelftc_vstr.o libelftc.a elftc.3.gz > elftc_bfd_find_target.3.gz elftc_copyfile.3.gz elftc_demangle.3.gz > elftc_reloc_type_str.3.gz elftc_set_timestamps.3.gz > elftc_timestamp.3.gz elftc_string_table_create.3.gz elftc_version.3.gz > elftc.3.cat.gz elftc_bfd_find_target.3.cat.gz elftc_copyfile.3.cat.gz > elftc_demangle.3.cat.gz elftc_reloc_type_str.3.cat.gz > elftc_set_timestamps.3.cat.gz elftc_timestamp.3.cat.gz > elftc_string_table_create.3.cat.gz elftc_version.3.cat.gz > rm -rf sys > rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS > ===> lib/libevent (cleandir) > rm -f buffer.o evbuffer.o event.o kqueue.o log.o poll.o select.o > signal.o buffer.po evbuffer.po event.po kqueue.po log.po poll.po > select.po signal.po buffer.pico evbuffer.pico event.pico kqueue.pico > log.pico poll.pico select.pico signal.pico libprivateevent.so > libprivateevent.so.1.full libprivateevent.so.1.debug libprivateevent.a > libprivateevent_p.a libprivateevent.so.1 > rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS > ===> lib/libexecinfo (cleandir) > rm -f backtrace.o symtab.o unwind.o backtrace.po symtab.po unwind.po > backtrace.pico symtab.pico unwind.pico libexecinfo.so > libexecinfo.so.1.full libexecinfo.so.1.debug libexecinfo.a > libexecinfo_p.a libexecinfo.so.1 backtrace.3.gz backtrace.3.cat.gz > rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS > ===> lib/libexpat (cleandir) > rm -f bsdxml.h bsdxml_external.h xmlparse.o xmlrole.o xmltok.o > xmlparse.po xmlrole.po xmltok.po xmlparse.pico xmlrole.pico > xmltok.pico libbsdxml.so libbsdxml.so.4.full libbsdxml.so.4.debug > libbsdxml.a libbsdxml_p.a libbsdxml.so.4 libbsdxml.3.gz > libbsdxml.3.cat.gz > rm: bsdxml.h: Permission denied > rm: bsdxml_external.h: Permission denied > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/lib/libexpat > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src/lib > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > The "rm -f bsdxml.h bsdxml_external.h ..." looks dodgy to me. Why have > these 2 files in the source tree if it's going to be removed early in > the build? What's the output of "svnlite st" in /usr/src? Did you run make in /usr/src/lib/libexpat as root? Try: # cd /usr/src/lib/libexpat # make cleandir -- Herbert From owner-freebsd-stable@freebsd.org Tue May 2 16:37:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BEC1D5B8A9 for ; Tue, 2 May 2017 16:37:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B761F84 for ; Tue, 2 May 2017 16:37:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v42GbCpu012939 for ; Tue, 2 May 2017 16:37:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837) Date: Tue, 02 May 2017 16:37:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: peixoto.cassiano@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 16:37:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213903 --- Comment #30 from Cassiano Peixoto --- Hi Mateusz, Any update about this issue? Thanks. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Thu May 4 16:35:19 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13F6CD5DE11 for ; Thu, 4 May 2017 16:35:19 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy21.sbb.rs (mproxy21.sbb.rs [89.216.2.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.sbb.rs", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EFF01D70 for ; Thu, 4 May 2017 16:35:17 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from faust.localdomain ([87.116.180.177]) by mproxy21.sbb.rs (8.15.2/8.15.2) with ESMTP id v44G6MIo032454 for ; Thu, 4 May 2017 18:06:22 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.7 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id C1E16A554BB; Thu, 4 May 2017 18:06:23 +0200 (CEST) Date: Thu, 4 May 2017 18:06:23 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: asus m5a97 problem Message-ID: <20170504160623.GA1710@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy21.sbb.rs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:35:19 -0000 Dear all! After mobo battery failed, being replaced, I got strange hwpstate err 6 problem. Qool and quiet, c1e and c6 are enabled. When they are, I see this error. It makes no problem at all, but I dislike to se it in console. Turning q'n'q off, it is gone. I found a thread, but seems it was solved just having HPC off. Still 9.3. I plan to upgrade to 11 directly, but just don't right now. Best regards. Zoran From owner-freebsd-stable@freebsd.org Thu May 4 20:16:12 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 954F2D5E063 for ; Thu, 4 May 2017 20:16:12 +0000 (UTC) (envelope-from cara.john@ragtechnology.com) Received: from smtp105.biz.mail.ne1.yahoo.com (smtp105.biz.mail.ne1.yahoo.com [98.138.207.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D0F4D41 for ; Thu, 4 May 2017 20:16:12 +0000 (UTC) (envelope-from cara.john@ragtechnology.com) Received: (qmail 79211 invoked from network); 4 May 2017 20:09:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1493928571; bh=wDiZpfVddPWRcO/kxh7qeAGKyyjr2hwNOCdFcZ9RqZQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=lOqxHPdO+1cskcm/BhiaAop1yNON3G4wJAuKhm8pQeu4x12AfON7PlJnHkJ6cZmd4qvDlJAHxnvY0q1BwjPTvYz+xvu63VKlbVySKDPMmCfOhMxFYSFWp9Du4P/j8NM2qy7l/aqL5Z9/0FhK0G1mDOuqK7yyIj7Hh+V6StlY4f8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Jtdm7X0VM1li4KSMpYA25MvEN_z4gi7MBC64dtYLkRrpLHN Hh51E0jk0WQ6.It8IXYG.cQTvK2aesEVeXZeTMf8RUx5.Yt2Zx5J9VAf4bVf Y4yJqSc0v_oRJhSaNxGZVEUSonSg.yAHblMlymahEhJouSW8IPrgd655lLjq 0pALseJsc5CpvoE8n9yzWd0Wrk8xhRtfIf9EfL5l0YYESWlaZvhElLD6yZ_a quHBYRVwb8eC7vxOtRk8x2OUZvd76LlbdyXqPrNLRlaKQHEj3w2_2HOdtlHr FqyhgEBCaKwTgjeFQKhBClan1etXkZXJTyoOmUUXhBzIm9RCW_HnSdUy9ShX m9MuR1D73.XFvk92clFw.T5j43OIard2dCBDJ7hLMeDQQNyxR_H_xKrL0TvY 3_1i9r9C6CPm7KQ8qbw0axKqyFZ7NMYQM_56kftD_HrpL2kYKzjEc0LKCcQp kim4DbPp2raSUKap2Uou7VjTwJqalxXSgZVVGH3TpiyjxPJkTnyq5QsMezvQ AdE5ZRdQ4IRj.XbR_diYEGQboAS7IYkVaDiwvI5ptoJP6M.hij.HpV4SqVnK 4cDSvvyEh X-Yahoo-SMTP: gCGfXniswBAVtE1Y5QhOEQgEfZD_GKMn3p92MPnuN8nLTOKabzMm_TrhSj0BTYN.UlRhS5M- From: "Cara John" To: References: In-Reply-To: Subject: Bio-IT World Conference & Expo Attendees List 2017 Date: Thu, 4 May 2017 16:09:28 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 Importance: High Thread-Index: AdLE6/BX04APLrK2QGKemX3zbsBppQAJZnYgAAAADuAAAAAEQAAAAA+AAAAAFaAAAAAP0AAAABDQAAAAD8AAAAAO8AAALPKwAAAACvAAAAG6sAAAAkcQAAAACqAAAAAMAAAAABaQ Content-Language: en-in Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 20:16:12 -0000 Hi, =20 Would you be interested in acquiring an Bio-IT World Conference & Expo Attendees Email List 2017? which includes complete contact details and verified email addresses of :-=20 =20 Key decision Makers from Below sector :- =20 =D8 Pharmaceutical =D8 Clinical =D8 Healthcare =D8 IT professionals =D8 Commercial (Biotech + Pharma)=20 =D8 Financial & Services=20 =D8 Academic & Government =D8 Healthcare =D8 Executive & Director =D8 Scientist/Technologist=20 =D8 Sales & Marketing=20 =D8 Manager =D8 Professor =20 If you are interested please let me know your targeted criteria, I can assist you with the count/costs, and more details for your = consideration. =20 Looking forward to hear from you =20 Regards, Cara John Marketing Executive =20 From owner-freebsd-stable@freebsd.org Fri May 5 06:03:53 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2368FD5D477 for ; Fri, 5 May 2017 06:03:53 +0000 (UTC) (envelope-from asmodai@in-nomine.org) Received: from smtpq6.tb.mail.iss.as9143.net (smtpq6.tb.mail.iss.as9143.net [212.54.42.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D763132C for ; Fri, 5 May 2017 06:03:52 +0000 (UTC) (envelope-from asmodai@in-nomine.org) Received: from [212.54.42.117] (helo=lsmtp3.tb.mail.iss.as9143.net) by smtpq6.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d6WL9-0003Hn-U3 for freebsd-stable@FreeBSD.org; Fri, 05 May 2017 08:03:43 +0200 Received: from f65250.upc-f.chello.nl ([80.56.65.250] helo=nexus.in-nomine.org) by lsmtp3.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1d6WL9-0000L6-Rh for freebsd-stable@FreeBSD.org; Fri, 05 May 2017 08:03:43 +0200 Received: from nexus.domini.in-nomine.org (localhost [127.0.0.1]) by nexus.in-nomine.org (Postfix) with ESMTP id 82622E726D for ; Fri, 5 May 2017 08:03:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at in-nomine.org Received: from nexus.in-nomine.org ([127.0.0.1]) by nexus.domini.in-nomine.org (nexus.domini.in-nomine.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsOS9V46xO0u for ; Fri, 5 May 2017 08:03:40 +0200 (CEST) Received: by nexus.in-nomine.org (Postfix, from userid 1000) id 8E082E726B; Fri, 5 May 2017 08:03:40 +0200 (CEST) Date: Fri, 5 May 2017 08:03:40 +0200 From: Jeroen Ruigrok van der Werven To: freebsd-stable@FreeBSD.org Subject: 11-STABLE: vm_radix_remove: invalid key found panic Message-ID: <20170505060340.GB4975@nexus.in-nomine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organisation: In Nomine User-Agent: Mutt/1.8.2 (2017-04-18) X-SourceIP: 80.56.65.250 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=SoLg0LG0 c=1 sm=1 tr=0 a=uYckZ3MqabZapTekVh/itw==:17 a=IkcTkHD0fZMA:10 a=tJ8p9aeEuA8A:10 a=6I5d2MoRAAAA:8 a=KFxsFCGQAAAA:8 a=vE9nTFuV5aS3Wc8qoUkA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=6tCdMxT-lwBHHNnwEv14:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 06:03:53 -0000 So I logged https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219070 about a panic occurring with vm_radix_remove: invalid key found panic I need some help debugging this, because it has been ages since I did any decent kernel debugging. Especially with regard to the values that are optimized out as well as this subsystem, I am not entirely sure what to focus on first. I would imagine I want to go from frame 13 and check all the data structures for sanity. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | GPG: 2EAC625B I realise that nothing's as it seems... From owner-freebsd-stable@freebsd.org Sat May 6 15:01:56 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BBA3D5FCB7 for ; Sat, 6 May 2017 15:01:56 +0000 (UTC) (envelope-from admin@scienceknowconferences.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86F5B1A86 for ; Sat, 6 May 2017 15:01:54 +0000 (UTC) (envelope-from admin@scienceknowconferences.com) Received: from infong-uk72.kundenserver.de (infong-uk72.customerhosting.co.uk [217.160.62.17]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0MFn1t-1dIovO0PWH-00EaJo; Sat, 06 May 2017 17:01:47 +0200 Received: from 178.23.155.153 (IP may be forged by CGI script) by infong-uk72.kundenserver.de with HTTP id zLIWGw-1dwVNH0BVM-00s9eG; Sat, 06 May 2017 16:01:47 +0100 X-Sender-Info: <661228873@infong-uk72.kundenserver.de> Precedence: bulk To: Freebsd Stable Subject: Last Call - International Conferences in Spain 2017 DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; l=43976; s=acy; t=1494082907; c=relaxed/simple; h=from:to:subject; d=http://scienceknowconferences.com/; bh=0kspG/wEZmctsQnFQgn5TCF6MCY=; b=UeZKkRIwtJ4jZw8TKCOl28X1B98JjR0QigGhz3Kf1o79r4fiAo49pStgg8iK 9yqM1U8h0i6m21Sq0++ufkV3JgIsj28kFLhvFOl2/jWm3bwP1u/rNDUZHrYD 8uIifk3+EZNLjv9jy/2Bw+CMJv1/o03LCDy1l5tQ3mu3vwQ66Cs= Date: Sat, 6 May 2017 16:01:17 +0100 From: SCK Europe Reply-To: ScienceKNOW Message-ID: X-Mailer: PHPMailer 5.2.19 (https://github.com/PHPMailer/PHPMailer) MIME-Version: 1.0 X-Provags-ID: V02:K0:SMCN0un3RLEDHTyTAz1RBElq4t+Qa04tfwZyvbC8Fiv tZ1wW0mHz00F7QuJ+4rmjOfNWo0fmhwpbceCI0Ma2ISubj7KGZ UshCkeruCwdWJEeObvVm6GOLoUOSg4NjT2ueYXhY+ygXg08VTZ CPze2RXpeevz4wv13H++0jrNGe4d2ue9NXmNGdWfs92MyIGgGh GqDDnbsI8YQ1A4mpuhU5ZwzQ9LTwpTsgbY0Rfp5ROPG+P/+I1X z/xbq/hyM4pNDSDSkOV+NfvaZqhO9o5x8SV4VFa2liabMbnjsj vpDo4+YeW8LavC0AzPdEXZ2w/KpKxJ31TB9K+gF358+2quqeAJ jODgMjXt9Of9p39KBTOQMG4Y/B6k3Y385771TBwraKomuOXf1T F2u+CTfgUsACPS9lrjBdAOpHo4R3ATFbvhPgwhd9JFACCZBUQs ekWyu X-UI-Out-Filterresults: notjunk:1;V01:K0:FhxUMwIskJs=:XGWnXvnn9dT5KFsMPKvg56 bZDr5vhACL7fJkTkim/HVZVfD7r8ZRsnxRzXGSf0DxUjCsu0MBAKrJ4L110JQAhbfpsSlSX1G 8XD5UiprCNhM7u3aYc7JgY8CSGT9xx3mxnpaG4o50CcZ0N77zXoH1fUOiuWUVL8bO+qeFdUKt dSOaQGl7cq8PZ59fWJL3u3j+idPaM24X4lLkeL/xkgcjSxIoZSsHr6s1dSkak9g+9WU6L0154 Ubd3LyxYRo96hplPZQqsm9YMU5uspLoatPRiJaeJKEpLP0gTuUDj7Vlbis= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 15:01:56 -0000 TEFTVCBDQUxMIEZPUiBQQVBFUlMgKEFQT0xPR0lFUyBGT1IgQ1JPU1MtUE9TVElORykNCg0KQWJz dHJhY3RzIHNlbmRpbmcgKEV4dGVuZGVkKTogSnVuZSA1dGggMjAxNw0KRWFybHkgQmlyZCByZWdp c3RyYXRpb246IEp1bmUgMTB0aCAyMDE3DQpEZWFyIENvbGxlYWd1ZSwNCldlIHdvdWxkIGxpa2Ug dG8gaW52aXRlIHlvdSB0byBjb21lIGFzIEludml0ZWQgQXV0aG9yIGluIG91ciBDb25mZXJlbmNl cyB0aGF0IHdpbGwgYmUgaGVsZCBpbiB0aGUgQ2FuYXJ5IElzbGFuZHMgKApodHRwOi8vc2NpZW5j ZWtub3djb25mZXJlbmNlcy5jb20vaW5kZXgucGhwP3N1YmlkPTE2MjI0NzMmb3B0aW9uPWNvbV9h Y3ltYWlsaW5nJmN0cmw9dXJsJnVybGlkPTY4NCZtYWlsaWQ9MjkyICksIFNwYWluIChVRSksIGlu IEp1bHkgMjAxNzoNCg0KSU5URVJOQVRJT05BTCBDT05GRVJFTkNFUyBTUEFJTiAyMDE3DQoNCmh0 dHA6Ly93d3cuY2hlbWJpb2NoZW1lbmcuY29tLyAoIGh0dHA6Ly9zY2llbmNla25vd2NvbmZlcmVu Y2VzLmNvbS9pbmRleC5waHA/c3ViaWQ9MTYyMjQ3MyZvcHRpb249Y29tX2FjeW1haWxpbmcmY3Ry bD11cmwmdXJsaWQ9Njg1Jm1haWxpZD0yOTIgKQ0KMm5kIEludGVybmF0aW9uYWwgQ29uZmVyZW5j ZSBvbiBDaGVtaWNhbCBhbmQgQmlvY2hlbWljYWwgRW5naW5lZXJpbmcgKElDQ0JFMikNCjI0LTI2 IEp1bHksIDIwMTcNCkNhbmFyeSBJc2xhbmRzLCBTUEFJTg0KDQpodHRwOi8vd3d3LmNvbXB1dGVy c2NpZW5nLmNvbSAoIGh0dHA6Ly9zY2llbmNla25vd2NvbmZlcmVuY2VzLmNvbS9pbmRleC5waHA/ c3ViaWQ9MTYyMjQ3MyZvcHRpb249Y29tX2FjeW1haWxpbmcmY3RybD11cmwmdXJsaWQ9Njg2Jm1h aWxpZD0yOTIgKQ0KMm5kIEdsb2JhbCBDb25mZXJlbmNlIG9uIEFwcGxpZWQgQ29tcHV0aW5nIGlu IFNjaWVuY2UgYW5kIEVuZ2luZWVyaW5nIChBQ1NFMikNCjI2LTI4IEp1bHkgMjAxNw0KQ2FuYXJ5 IElzbGFuZHMsIFNQQUlODQoNCmh0dHA6Ly93d3cuc21hdHNjaXRlY2guY29tICggaHR0cDovL3Nj aWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tL2luZGV4LnBocD9zdWJpZD0xNjIyNDczJm9wdGlvbj1j b21fYWN5bWFpbGluZyZjdHJsPXVybCZ1cmxpZD02ODcmbWFpbGlkPTI5MiApDQoybmQgSW50ZXJu YXRpb25hbCBDb25mZXJlbmNlIG9uIFN1c3RhaW5hYmxlIE1hdGVyaWFscyBTY2llbmNlIGFuZCBU ZWNobm9sb2d5IChTTVNUMikNCjE5LTIxIEp1bHksIDIwMTcNCkNhbmFyeSBJc2xhbmRzLCBTUEFJ Tg0KDQpodHRwOi8vd3d3LmVudmlyb25tZW50YWxlbmc3LmNvbSAoIGh0dHA6Ly9zY2llbmNla25v d2NvbmZlcmVuY2VzLmNvbS9pbmRleC5waHA/c3ViaWQ9MTYyMjQ3MyZvcHRpb249Y29tX2FjeW1h aWxpbmcmY3RybD11cmwmdXJsaWQ9Njg4Jm1haWxpZD0yOTIgKQ0KN3RoIEludGVybmF0aW9uYWwg Q29uZ3Jlc3Mgb24gRW5lcmd5IGFuZCBFbnZpcm9ubWVudCBFbmdpbmVlcmluZyBhbmQgTWFuYWdl bWVudCAoQ0lJRU03KQ0KMTctMTkgSnVseSAyMDE3DQpDYW5hcnkgSXNsYW5kcywgU1BBSU4NCg0K SW52aXRlZCBBdXRob3JzIGhhdmUgdGhlIGZvbGxvd2luZyBiZW5lZml0czoNCg0KKiANClByaW9y aXR5IGluIHRoZSBjb25mZXJlbmNlIHByb2dyYW0uDQoNCiogDQpQcmlvcml0eSB0byBzdWJtaXQg eW91ciBleHRlbmRlZCBwYXBlciB0byBDb25ncmVzcyBKb3VybmFscyAoRWxzZXZpZXIsIERlR3J1 eXRlciBhbmQgVHJhbnN0ZWNoIEVkaXRvcmlhbCBQdWJsaWNhdGlvbnMpDQoNCiogDQpQb3NzaWJp bGl0eSBvZiBzdWJtaXR0aW5nIGEgdGhpcmQgYWJzdHJhY3QgZnJlZSBvZiBjaGFyZ2UuDQoNCiog DQpJbnZpdGVkIEF1dGhvcnMgd2lsbCByZWNlaXZlIGEgQ2VydGlmaWNhdGUgZnJvbSB0aGUgU2Vj cmV0YXJpYXQgKGxpbWl0ZWQgbnVtYmVyKQ0KDQoqIA0KSW52aXRlZCBBdXRob3JzIGNhbiBiZSBp bmNsdWRlZCBpbiB0aGUgU2NpZW50aWZpYyBDb21taXR0ZWUgb2Ygb3VyIGZ1dHVyZSBjb25mZXJl bmNlcyBvZiAyMDE4DQoNCiogDQpJbnZpdGF0aW9uIGZvciBDby1vcmdhbml6aW5nIGEgZnV0dXJl IFNjaWVuY2VLTk9XIEV2ZW50cy4NCg0KUHVibGljYXRpb24NClBvc3NpYmlsaXR5IG9mIHB1Ymxp Y2F0aW9uIGZvciBhdXRob3JzIGluIGhpZ2gtcHJvZmlsZSBqb3VybmFsczoNCg0KKiANCkpvdXJu YWwgb2YgRW52aXJvbm1lbnRhbCBNYW5hZ2VtZW50LCBFbHNldmllcg0KDQoqIA0KQWR2YW5jZWQg TWF0ZXJpYWxzIFJlc2VhcmNoLCBUcmFuc3RlY2ggUHVibGljYXRpb25zDQoNCiogDQpBZHZhbmNl ZCBFbmdpbmVlcmluZyBGb3J1bSwgVHJhbnN0ZWNoIFB1YmxpY2F0aW9ucw0KDQoqIA0KT3BlbiBD b21wdXRlciBTY2llbmNlLCBEZSBHcnV5dGVyDQoNCiogDQpQYWxhZHluLCBKb3VybmFsIG9mIEJl aGF2aW9yYWwgUm9ib3RpY3MsIERlIEdydXl0ZXINCg0KKiANCkluZm9ybWF0aWNzLCBNRFBJIA0K DQpPcmdhbml6aW5nIENvbW1pdHRlZQ0KVGhlIE9yZ2FuaXppbmcgQ29tbWl0dGVlIG9mIHRoZSBD b25mZXJlbmNlcyBiZWxvbmdzIHRvIHRoZSBmb2xsb3dpbmcgaW5zdGl0dXRpb25zOg0KDQoqIA0K VW5pdmVyc2l0eSBvZiBFeHRyZW1hZHVyYSwgU3BhaW4NCg0KKiANCkMzaS9Qb2x5dGVjaG5pYyBJ bnN0aXR1dGUgb2YgUG9ydGFsZWdyZSwgUG9ydHVnYWwNCg0KKiANClVuaXZlcnNpdHkgb2YgTGFz IFBhbG1hcyBkZSBHcmFuIENhbmFyaWEsIFNwYWluDQoNCiogDQpVbml2ZXJzaXR5IG9mIFRleGFz IGF0IEVsIFBhc28sIFVTQQ0KDQoqIA0KUG9seXRlY2huaWMgVW5pdmVyc2l0eSBvZiBWYWxlbmNp YSwgU3BhaW4NCg0KKiANCkdvZ3RlIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5LCBJbmRpYQ0KDQoq IA0KUG9seXRlY2huaWMgSW5zdGl0dXRlIG9mIFBvcnRvLCBQb3J0dWdhbA0KDQpUb3VyaXNtIGlu IENhbmFyeSBJc2xhbmRzLCBhIFBhcmFkaXNlIGluIHRoZSBXb3JsZCAhDQogVmlkZW86IENhbmFy eSBJc2xhbmRzICggaHR0cDovL3NjaWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tL2luZGV4LnBocD9z dWJpZD0xNjIyNDczJm9wdGlvbj1jb21fYWN5bWFpbGluZyZjdHJsPXVybCZ1cmxpZD02ODkmbWFp bGlkPTI5MiApDQogUGhvdG86IENhbmFyeSBJc2xhbmRzICggaHR0cDovL3NjaWVuY2Vrbm93Y29u ZmVyZW5jZXMuY29tL2luZGV4LnBocD9zdWJpZD0xNjIyNDczJm9wdGlvbj1jb21fYWN5bWFpbGlu ZyZjdHJsPXVybCZ1cmxpZD02OTAmbWFpbGlkPTI5MiApDQpUaGUgQ2FuYXJ5IElzbGFuZHMgYXJl IHNldmVuIGlzbGFuZHMgaW4gdGhlIEF0bGFudGljIE9jZWFuIHdoZXJlIHRoZSBzdW4gc2hpbmVz IGFsbCB5ZWFyIHJvdW5kLiBUaGUgdGVtcGVyYXR1cmVzIGFyZSB2ZXJ5IG1pbGQsIHdpdGggYW4g YXZlcmFnZSBvZgoxOcK6IEMgaW4gd2ludGVyIGFuZCAyM8K6IEMgaW4gc3VtbWVyLiBXaGVuIHlv dSBzdHJvbGwgYWxvbmcgdGhlaXIgYmVhY2hlcyBvciBpbW1lcnNlIHlvdXJzZWxmIGluIHRoZWly IGltcG9zaW5nIGxhbmRzY2FwZXMgeW91J2xsIGZlZWwgeW91ciBjYXJlcwpzaW1wbHkgbWVsdCBh d2F5LiANCg0KQWxsIG91ciBjb25mZXJlbmNlcyBpbmNsdWRlIGEgRlJFRS1HVUlERUQgVE9VUiBJ TiBHUkFOIENBTkFSSUEgKENBTkFSWSBJU0xBTkRTKQ0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgeW91 IGNhbiBhZGRyZXNzIGFsbCB5b3VyIGNvbW1lbnRzL3F1ZXN0aW9ucy9zdWdnZXN0aW9ucyB0byBp bmZvQHNjaWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tICggbWFpbHRvOmluZm9Ac2NpZW5jZWtub3dj b25mZXJlbmNlcy5jb20KKQ0KDQpMb29raW5nIGZvcndhcmQgdG8gd2VsY29taW5nIHlvdSBhZ2Fp biBpbiB0aGUgQ2FuYXJ5IElzbGFuZHMsDQoNCllvdXJzIGZhaXRoZnVsbHksDQpTY2llbmNlS05P VyBDb25mZXJlbmNlcyBUZWFtDQpTcGFpbiwgVUUNCkUtbWFpbDogaW5mb0BzY2llbmNla25vd2Nv bmZlcmVuY2VzLmNvbSAoIG1haWx0bzppbmZvQHNjaWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tICkN Cg0KUGxlYXNlIHZpc2l0IGNvbmdyZXNzZXMnIHdlYnBhZ2VzIHRvIGdldCBhbGwgdGhlIGluZm9y bWF0aW9uIG9uIHRvcGljcywgaW1wb3J0YW50IGRhdGVzIGFuZCBhbGwgdGhlIGltcG9ydGFudCBp bmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBjb25ncmVzcw0KDQpXYW50IHRvIGJlIHJlbW92ZWQ/ IE5vIHByb2JsZW0sIGNsaWNrIGhlcmUgKApodHRwOi8vc2NpZW5jZWtub3djb25mZXJlbmNlcy5j b20vaW5kZXgucGhwP3N1YmlkPTE2MjI0NzMmb3B0aW9uPWNvbV9hY3ltYWlsaW5nJmN0cmw9dXNl ciZ0YXNrPW91dCZtYWlsaWQ9MjkyJmtleT1iUWVyQ1FleTdndjViaiApIGFuZCB3ZSdsbCByZW1v dmUKeW91ciBlLW1haWwgYWRkcmVzcy4NCg0KKApodHRwOi8vc2NpZW5jZWtub3djb25mZXJlbmNl cy5jb20/dXRtX3NvdXJjZT1uZXdzbGV0dGVyXzI5MiZ1dG1fbWVkaXVtPWVtYWlsJnV0bV9jYW1w YWlnbj1sYXN0LWNhbGwtaW50ZXJuYXRpb25hbC1jb25mZXJlbmNlcy1pbi1zcGFpbi0yMDE3JmFj bT0xNjIyNDczXzI5MgopDQppbmZvQHNjaWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tICggbWFpbHRv OmluZm9Ac2NpZW5jZWtub3djb25mZXJlbmNlcy5jb20gKSB3d3cuc2NpZW5jZWtub3djb25mZXJl bmNlcy5jb20gKApodHRwOi8vOTQuMTI2LjE3Mi4zMS9wbGVzay1zaXRlLXByZXZpZXcvd3d3LnNj aWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tLzk0LjEyNi4xNzIuMzEvP3V0bV9zb3VyY2U9bmV3c2xl dHRlcl8yOTImdXRtX21lZGl1bT1lbWFpbCZ1dG1fY2FtcGFpZ249bGFzdC1jYWxsLWludGVybmF0 aW9uYWwtY29uZmVyZW5jZXMtaW4tc3BhaW4tMjAxNyZhY209MTYyMjQ3M18yOTIKKQ0KDQpJbiBj b21wbGlhbmNlIHdpdGggdGhlIGN1cnJlbnQgU3BhbmlzaCBsZWdpc2xhdGlvbiBvbiBTZXJ2aWNl cyBvZiB0aGUgSW5mb3JtYXRpb24gU29jaWV0eSBhbmQgRWxlY3Ryb25pYyBDb21tZXJjZSwgb2Yg UGVyc29uYWwgRGF0YSBQcm90ZWN0aW9uIGFuZCB0aGUKRGlyZWN0aXZlIDk1LzQ2L0NFLCB3ZSBp bmZvcm0geW91IHRoYXQgeW91ciBwZXJzb25hbCBkYXRhIGZvcm1zIHBhcnQgb2YgYSBkYXRhIGJh c2UgbWFuYWdlZCB1bmRlciBvdXIgcmVzcG9uc2FiaWxpdHksIHdpdGggdGhlIG9iamVjdGl2ZSB0 byBtYWludGFpbgp0aGUgY29tbWVyY2lhbCBhbmQgY29udHJhY3R1YWwgcmVsYXRpb25zIGFuZCBp bmZvcm0geW91IGFib3V0IG5ld3MgYW5kIGV2ZW50cyByZWxhdGVkIHRvIG91ciBhY3Rpdml0eSwg ZWl0aGVyIGJ5IHlvdXIgY2xpZW50IHN0YXR1cywgYmVjYXVzZSB5b3XigJl2ZQpyZXF1ZXN0ZWQg Y29tbWVyY2lhbCBpbmZvcm1hdGlvbiBvciBiZWNhdXNlIHlvdXIgZGF0YSBpcyBpbmNsdWRlZCBp biBzb3VyY2VzIGFjY2VzaWJsZSB0byB0aGUgcHVibGljLiBPdXIgaW50ZW50aW9uIGlzIHRvIGF2 b2lkIHNlbmRpbmcgdW53YW50ZWQKZS1tYWlscy4gSWYgeW91IGRvbuKAmXQgd2lzaCB0byByZWNl aXZlIHRoaXMgdHlwZSBvZiBjb21tdW5pY2F0aW9uLCB5b3UgbWF5IG9iamVjdCB3aXRoIGEgc2lt cGxlIG5vdGlmaWNhdGlvbiBvZiB5b3VyIHdpbGwsIGFzIHdlbGwgYXMgdG8gZXhlcmNpc2UKeW91 ciByaWdodHMgb2YgYWNjZXNzLCByZWN0aWZpY2F0aW9uLCBjYW5jZWxsYXRpb24gYW5kIG9wcG9z aXRpb24gdG86IFNDSUVOQ0VLTk9XIENPTkZFUkVOQ0VTIENCLCBhdCBQTEFaQSBTQU4gSk9TRSBE RSBNQU5ZQU5FVCA5IEJBSk8gQiwgMDYwMDYKQkFEQUpPWiAtIFNQQUlOLCBieSBwaG9uZSArMzQg NjU2NDA1MjM5LCBieSBlLW1haWwgaW5mb0BzY2llbmNla25vd2NvbmZlcmVuY2VzLmNvbSBvciBi eSBjbGlja2luZyBoZXJlICgKaHR0cDovL3NjaWVuY2Vrbm93Y29uZmVyZW5jZXMuY29tL2luZGV4 LnBocD9zdWJpZD0xNjIyNDczJm9wdGlvbj1jb21fYWN5bWFpbGluZyZjdHJsPXVzZXImdGFzaz1v dXQmbWFpbGlkPTI5MiZrZXk9YlFlckNRZXk3Z3Y1YmogKS4gVGhpcyBlLW1haWwgYW5kCmFueSBv dGhlciBmaWxlcyBpbmNsdWRlZCBvbiBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBjb250YWluIGlu Zm9ybWF0aW9uIHN1YmplY3QgdG8gcHJvZmVzc2lvbmFsIHNlY3JlY3kgb3Igd2hpY2ggZGl2dWxn YXRpb24gaXMgZXhwcmVzc2x5IGZvcmJpZGVuIGJ5Ckxhdy4gVGhpcyBlLW1haWwgaXMgZXhjbHVz aXZlbHkgZGlyZWN0ZWQgdG8gaXTigJlzIHJlY2VpdmVyLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBp dCBieSBtaXN0YWtlLCB3ZSBhc2sgeW91IHRvIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsIGFu ZCBwcm9jZWVkCnRvIGRlbGV0ZSBpdC4gVGhlIG5vbi1hdXRob3JpemVkIHVzZSBvZiB0aGlzIGUt bWFpbCBhbmQgaXRzIGZpbGVzIGlzIHN0cmljdGx5IGZvcmJpZGVuLg0K