From owner-freebsd-ports@freebsd.org Sun Nov 11 13:50:34 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDF321105B04 for ; Sun, 11 Nov 2018 13:50:33 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4953C819B9; Sun, 11 Nov 2018 13:50:33 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 39412B8DE; Sun, 11 Nov 2018 13:50:33 +0000 (UTC) From: Jan Beich To: Grzegorz Junka Cc: freebsd-ports@freebsd.org Subject: Re: Few how-it-works questions References: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> Date: Sun, 11 Nov 2018 14:50:29 +0100 In-Reply-To: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> (Grzegorz Junka's message of "Sun, 11 Nov 2018 12:34:25 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4953C819B9 X-Spamd-Result: default: False [-106.79 / 200.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; ALLOW_DOMAIN_WHITELIST(-100.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE(-3.69)[ip: (-9.62), ipnet: 96.47.64.0/20(-4.81), asn: 11403(-3.90), country: US(-0.09)]; MX_GOOD(-0.01)[cached: mx66.freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 13:50:34 -0000 Grzegorz Junka writes: > 1. Recommended way of upgrading ports is "poudriere ports -p local > -u", right? But this always gets me the latest version, in which some > ports may not compile, depending on my luck. I know I can use SVN to > checkout a specific version of ports instead, but is it possible to > find out in which SVN version which ports are compiling and which are > not? In other words, can I open the history of builds of FreeBSD ports > on the build servers and check which ports are building in a specific > SVN version, then checkout that version to build on my server? Navigate from https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 to get a list of SVN revisions built then check build log for each until you get one from a successful build. Inspecting /latest-per-pkg// on a package builder may help to filter results more quickly based on PKGVERSION but it doesn't change on every SVN revision. > 2. Every time poudriere builds a new set of packages, it deletes those > which have changed in ports or for which the options have changed, > then it tries to build them again. But because the ports change, some > may no longer build. In that case I am left with no packages to > install on a system unless I am lucky enough to be able to cleanly > build all ports again. What is the preferred strategy to maintain old > packages until a new set is build correctly? See KEEP_OLD_PACKAGES=3Dyes in poudriere.conf.sample. > > 3. When a package doesn't build because of a patch error: > > =3D=3D=3D>=C2=A0 Patching for ImageMagick6-6.9.10.14,1 > =3D=3D=3D>=C2=A0 Applying FreeBSD patches for ImageMagick6-6.9.10.14,1 > 1 out of 1 hunks failed--saving rejects to config/policy.xml.rej > =3D> FreeBSD patch patch-config_policy.xml failed to apply cleanly. > *** Error code 1 > > Is this a problem with the ports tree, the upstream package, or some > other package? There's no generic answer. It can happen if the ports tree is inconsistent, the upstream source have changed but downstream maintainer forgot to rebase or a master port updated but its slave wasn't tested. > In other words, can that problem be fixed without having an updated > version of the port Yes, by cherry-picking desired commit(s) fixing the issue.=20 > Are patches always kept in the ports tree or sometimes they may be > kept separately (e.g. in another repo versioned independently)? Depends on the port. Usually, patches are under files/ but backports or extra features maybe defined via PATCH_SITES or EXTRA_PATCHES. In rare cases patches maybe *within* distfile.