From owner-freebsd-current@FreeBSD.ORG Sat Oct 26 00:18:14 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 225942A7; Sat, 26 Oct 2013 00:18:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D12DF2BF4; Sat, 26 Oct 2013 00:18:13 +0000 (UTC) Received: from glenbarber.us (unknown [64.197.173.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id A0F7FD5AF; Sat, 26 Oct 2013 00:18:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us A0F7FD5AF Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 25 Oct 2013 20:18:01 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: 10.0-BETA2, why it is late... Message-ID: <20131026001801.GB1740@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 00:18:14 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline To keep everyone informed on what is taking so long with 10.0-BETA2, here is where we stand at the time of this writing: - A problem was found after freebsd-update(8) builds were finished for 10.0-BETA1 which, because of a file within contrib/openpam containing a tilde ('~'), would cause freebsd-update(8) to error when updating a system. This is a problem that was discovered during the 9.2-RELEASE cycle, but worked around for that release cycle. A more permanent fix has been committed to head/, and merged to stable/10. - During testing of the fix for the openpam filename problem, it was discovered that order in which freebsd-update(8) would install files to the new directory '/usr/lib/private' collided with the creation of the '/usr/lib/private' directory. This caused some shared libraries ('.so.N') files to attempt installation prior to the existence of the directory, which would cause an error. - Since between 9.x and 10.x, libc.so is a "regular" file (not a symlink to a shared library), freebsd-update(8) thought '/usr/lib/libc.so' was a shared library that should be removed/replaced as part of the upgrade. This caused the removal of '/usr/lib/libc.so', and subsequently, unfortunate side-effects. - CTF was found to be leaking build-host information into the resulting release build. Specifically, lines 130-133 define 'VERSION' as 'uname -srp', if otherwise unset. The negative effect of this is, in the event the release build machine and the freebsd-update build machine are out of sync (userland and kernel), the freebsd-update(8) run to upgrade a system would unnecessarily update everything within /boot/kernel/. It has been pointed out that r257136 to stable/10 has an unfortunate side effect of warning output from make(1) during the 'make delete-old' and 'make delete-old-libs'. Unfortunately, the fix for the CTF pollution is unclear at this point, but this will be correctly fixed. For 10.0-BETA2, we will need to ignore the messy output for now. I do not like it either, to be honest. Please keep in mind: This is *not*, by any evaluation, fault of freebsd-update(8). This is the natural progression of software, and these issues are result of infrastructural changes on multiple levels. Please bear with us; we'll have 10.0-BETA2 started soon. Glen --96YOpH+ONegL0A3E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSawo4AAoJELls3eqvi17QF7wP/ieDuaaM9i/FPkuRg7rLxe1o 3oKaX8q1Efs6cz/50sOcKThTo2zwo1JlT0YHcMNWwF6lRpxQeBWtne1ndlO3I2EG cXfBDrqEln5jLkFceQ6xg4k69Vk9MEnEWTbDDCDpTXvV23W+RbO9LRlASnvCdDtG wtEMO8mUg+uwc0VasYVu2h2kMEWnXTLV1H3D4FFlktAJjERgqdKK7RI60F7GG+n9 Hjxywo4OgqJCNqq0pi3hONMyhYulrIm6Xykg1a4++WMlE015Dw2K21OvkA2gN7Rx NqNdCoF/r/ro1fbQ0TW+AsPU2slIFgxyqMEBjZI+F72fo4zYW5eGW6k6ZKNBXhzQ v+0xA7B6vZkX6yD2m+pqjBKnwuR/V/WuS+c3ocODOG5jDGLMf9M9Raxx3CW0UK5X /VNeWCKW6Xydh3Ij+C9aXT6L+FSIwyJMut+NfZHj9Bh88NPIjlorSx031ErM7ztK EuQ8XJUg4n9287WzYLmhrGuZgl1hIf0FLo2AtpTMAGNicd5DTv1biZrgGsL1IQQv 87p6wTxJyPEC/jNypV34x82MTG3lTSjEdehVLMFkVwBlTLHRC+VTdC+UccRyV3uo z89JkPW9cxhQpJZk14aoyOS108tTVPph74b2uXU2evsHOHeedeZ7nZW2sqIWbgc1 zuHtmD/xgLBCqE8l/Hxz =OEK1 -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E--