From owner-svn-src-all@FreeBSD.ORG Mon Nov 18 20:40:42 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 814635DA; Mon, 18 Nov 2013 20:40:42 +0000 (UTC) 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 3BC412639; Mon, 18 Nov 2013 20:40:42 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (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 B5604144F1; Mon, 18 Nov 2013 20:40:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us B5604144F1 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 18 Nov 2013 15:40:38 -0500 From: Glen Barber To: Hiroki Sato Subject: Re: svn commit: r258310 - head/release Message-ID: <20131118204038.GU1643@glenbarber.us> References: <201311181625.rAIGPuRG078815@svn.freebsd.org> <20131119.034852.1148136397426813684.hrs@allbsd.org> <20131118195506.GT1643@glenbarber.us> <20131119.052924.2179352866091983302.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EsfvRFssnM00t552" Content-Disposition: inline In-Reply-To: <20131119.052924.2179352866091983302.hrs@allbsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:40:42 -0000 --EsfvRFssnM00t552 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2013 at 05:29:24AM +0900, Hiroki Sato wrote: > Glen Barber wrote > in <20131118195506.GT1643@glenbarber.us>: >=20 > gj> > gj> -export PKG_ABI=3D"freebsd:$(echo ${REVISION} | tr -d '.0'):x86= :64" > gj> > gj> +export PKG_ABI=3D"freebsd:$(echo ${REVISION} | sed -e 's/\.[0-= 9]//'):x86:64" > gj> > > gj> > PKG_ABI=3Dfreebsd:${REVISION%.[0-9]*}:x86:64 is simpler than invok= ing > gj> > tr or sed. However, pkg-stage.sh should have a mapping rule from > gj> > TARGET and TARGET_ARCH, not in arch specific config files, I think. > gj> > Other than the package list, variables are not arch-specific. > gj> > > gj> The pkg(8) ABI does not map directly to anything we use ('amd64' or > gj> 'i386') unfortunately. >=20 > Yes, it is true that it does not map TARGET/TARGET_ARCH directly. > What I mean is that it can be easily translated in pkg-stage.sh by > adding a mapping rule there like this: >=20 > case ${TARGET}:{TARGET_ARCH} in > amd64:*) PKG_ABI=3Dx86:64 ;; > ... > esac >=20 That is kind of the problem though. The ABI for amd64 is not x86:64, it is: $(uname -s | tr '[:upper:]' '[:lower:]'):${REVISION%.[0-9]}:x86:64 I do plan to redo quite a bit of this script, but it is good enough for a solution to the "we have nothing at all right now" problem for 10.0-RELEASE. > Depending files in arch-specific directory makes maintenance > difficult when the number of archs and combinations of > TARGET/TARGET_ARCH increase. It can happen when arm and mips are > handled in make release and the package server. Eliminating/reducing > manually-configured variables which can be derived from other ones is > always a good practice. >=20 > gj> > Does this guarantee that the packages downloaded by pkg(8) are for= a > gj> > specific release? And I think fetching packages can be done just > gj> > after svn co stage in release.sh. Collecting up necessity of netw= ork > gj> > access (including fetching distfiles for docproj) before entering = the > gj> > chroot environment makes redoing the release build easier. > gj> > > gj> > gj> I don't think it has been discussed yet where packages built for > gj> a specific release will exist. Anyway, I would like to avoid directo= ry > gj> hierarchy pollution outside of the dvd/ directory, this is why I use = it > gj> for PKG_CACHEDIR directly. >=20 > So I think it should be discussed and we should make the script to > consistently fetch the package set built from the release branch (or > head for stable or snapshots) in the ports tree. While I guess the > current one simply fetches the latest packages, the release iso > images must have packages which correspond to ports.txz. >=20 Agreed. Glen --EsfvRFssnM00t552 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSintGAAoJELls3eqvi17QIs8P/j9HVljmUxS4Y8nTT5L9EpXK GoZUo+2TculNkvk7/vtxDZRlujkwc3Qr8V3UEf1T6A+18CTAX+fFFGcRdXExnQpc MJ4e5g4f444Tt2ihlErlaoTF7C3pfAFFa+0RANIhZPG7kslcWir385lT6xQHrilN pjiWPzkOFASOLOr+m9L2c2+HT4oqkgNAQC2wxtbkuuRIHDJIZoUkHkoiZmvzFaS7 +3KzxbP1zjAd2wb7VToehdadWswOSJYF+4O7d/6JlXUSumOg6/jISUTYYVfsNrDf klxjmwFndLx5rVfSvVwQ32jsv78zEwNYvcXL7GUCgvB8dE8w7w7wBjJ7HUzmJ38F cd6oBiwKSx+fkc6soMmvvbTfZQl9a1tKjM0we6v8xLFSP55yBQZ6kTWJPvv4QqmC v0X5TUGHzqU7vPZxDhpVhZnVamdTpj44xdSpcs4YrgeDLiH3zx+yJubAA32dl99M eChia5Cm4GOl6I/0i9o4J3SDdNgs5yqz6AeMvaCmWDjg+nlT/03V3FQvOUpkif+V LJ7IY2zn3Qlt9jGT9Czo9uw+Sl+rpSiBMHG+2v2MTwsZHQG2SB8QR8Nb4xPBkYCY V86ZZHAqjYJxW1ZR47hP5RNFEgSsJ56EAKC9aX6lM5c7GfQWmilgQvavepxmpsdr 0grYwRqBG5QevyevfULS =IYBz -----END PGP SIGNATURE----- --EsfvRFssnM00t552--