From owner-cvs-all@FreeBSD.ORG Wed May 23 14:11:32 2012 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F1F5106566C; Wed, 23 May 2012 14:11:32 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from sup.oook.cz (sup.oook.cz [94.23.0.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7B68FC19; Wed, 23 May 2012 14:11:31 +0000 (UTC) Received: from [10.2.0.34] ([212.24.129.198]) (authenticated bits=0) by sup.oook.cz (8.14.4/8.14.4) with ESMTP id q4NEBUgG028806 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 May 2012 16:11:31 +0200 (CEST) (envelope-from pav@FreeBSD.org) From: Pav Lucistnik To: Baptiste Daroussin In-Reply-To: <20120523140611.GA64580@ithaqua.etoilebsd.net> References: <201205231334.q4NDYCMQ078804@repoman.freebsd.org> <1337780396.2024.2.camel@pav.hide.vol.cz> <9b15e44319f017bff90bc3caa1de79d9@bluelife.at> <1337781238.2024.7.camel@pav.hide.vol.cz> <20120523140611.GA64580@ithaqua.etoilebsd.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 May 2012 16:11:20 +0200 Message-ID: <1337782280.2024.10.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 94.23.0.135 Cc: cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org, Bernhard Froehlich , cvs-all@FreeBSD.org, Martin Wilke Subject: Re: cvs commit: ports/databases/pg_filedump Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:11:32 -0000 Baptiste Daroussin píše v st 23. 05. 2012 v 16:06 +0200: > On Wed, May 23, 2012 at 03:53:58PM +0200, Pav Lucistnik wrote: > > Bernhard Froehlich píše v st 23. 05. 2012 v 15:47 +0200: > > > On 23.05.2012 15:39, Pav Lucistnik wrote: > > > > Martin Wilke píše v st 23. 05. 2012 v 13:34 +0000: > > > >> miwi 2012-05-23 13:34:12 UTC > > > >> > > > >> FreeBSD ports repository > > > >> > > > >> Modified files: > > > >> databases/pg_filedump Makefile > > > >> Log: > > > >> - Switch to FETCH_DEPENDS to fix fetch during build > > > > > > > > How is this supposed to work? The log message makes no sense. > > > > > > The problem that this fixes is when you are building in jails > > > and restrict internet access to the "fetch" target like > > > pointyhat-west, redports.org and poudriere already do. > > > > Well, the restriction was put in place for a reason 1*), and now you're > > working around that very reason. So just remove the restriction from > > pointyhat and problem solved. > > > > What you are doing now is a nonsensical hack and I have to ask you to > > back it out. > > > > > > 1*) To have full control over what is being fetched from Internets, with > > help of checksums and distinfo lists. > > > > Maybe, in that case it will be good to define what we really wants/need and what > clusteradm and security people will accept. > > Should network access be restricted at any moment during the package building, > on automated build environment, if yes what phases are to be expected to be > restricted? > > Possibilities are: > - plain access until build target and no access from build target to the end? > (what about tests that needs network access should we allow them?) > - plain access during the whole phases but build? > - plain access all the time? > - [insert your proposition here :)] > > the restricttion in case of redports was a requirement (Bernhard has more > information about this than I do) > > Once it is decided changing pointyhat, redports, poudriere and upcoming jailed > tinderbox is easy. > > In my mind I see the fetch target as all I need to build that package should be > done by it and that is why it has been implemented that way. I think the current level of restrictions is OK. The systematic problem is that triple-tuple dependency targets (ie foo:port:build) invokes a build inside a build and thus does not respect the separation to fetch/build/... stages. This should be fixed, somehow. Not sure how. The whole triple-tuple feature is a pain, really.