Date: Sun, 11 Nov 2018 14:27:04 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports@freebsd.org Subject: Re: Few how-it-works questions Message-ID: <ea0d5d27-eacb-c5c9-c73d-6eaea2d6ab8e@FreeBSD.org> In-Reply-To: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> References: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fxnYY8hyzuSWR0sdfqIbMjEuCGpFXmi1z Content-Type: multipart/mixed; boundary="NLQWEpMMScxieNvHpVNtUREIyeMdcGnPC"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports@freebsd.org Message-ID: <ea0d5d27-eacb-c5c9-c73d-6eaea2d6ab8e@FreeBSD.org> Subject: Re: Few how-it-works questions References: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> In-Reply-To: <73366a94-238a-ed9a-5dee-d5955525e851@gjunka.com> --NLQWEpMMScxieNvHpVNtUREIyeMdcGnPC Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 11/11/2018 12:34, Grzegorz Junka wrote: > Hi All, >=20 > I would like to understand a bit better how the ports infrastructure wo= rks. >=20 > 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? Firstly ports rarely stay uncompilable for very long. There are exceptions mostly due to situations like the problems with openssl-1.1.1 support at the moment. So there are some additional strategies to apply:= 1) Wait. If you can just put off updating for a day or two, problems are quite likely to get fixed. Of course, you can help this process along by opening bug reports and/or submitting fixes or even just posting to the various lists about problems you're experiencing. 2) Change versions: since you're building your own packages, you don't need to stick with the default versions of things like python, postgres, openssl etc. set in the ports. Sometimes just substituting in a different version of a major dependency will solve your compilation problems. At the moment this is particularly fruitful with packages that need OpenSSL or an equivalent, given compatibility problems with libressl and recent openssl. 3) Change options: do you really need support for all of the possible whizz-bang features available in the downstream port? In many cases you can prune the dependency tree of a package pretty effectively by tweaking package options. Limit what's built to just what you actually need to use and you've cut out many places where failures could occur. By doing these things, you can generally get yourself a set of packages that you can build fairly reliably from the head of the ports tree. Now, you can play with checking out an older version of the ports and you can look at the results from the package build cluster eg. here: https://pkg-status.freebsd.org/?all=3D1 where there are historical logs, and you can compare against the commit history for your ports of interest to find when a problem was introduced and checkout the corresponding version of the ports tree. However... see below. > - also, is the ports tree mirrored in Git/GitHub? Yes. Here: https://github.com/freebsd/freebsd-ports.git > 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? Copy the whole folder aside? Is it possible= > to tell poudriere to create a new folder with packages for each new > build (eventually with the option to use already built packages when > they have not changed)? I suspect poudriere doesn't maintain such state= > internally, it simply deletes what's no longer relevant and then builds= > what's missing? Yes, poudriere can keep a history of the state of your package repository over time. Check the values of these settings in your poudriere.conf: ATOMIC_PACKAGE_REPOSITORY=3Dyes KEEP_OLD_PACKAGES=3Dyes KEEP_OLD_PACKAGES_COUNT=3D15 Poudriere will create a new directory tree for each package bulk you run, and link the unchanged packages into each tree for an incremental update so it's as space efficient as it can be. Poudriere will create a symbolic link in eg. /usr/local/poudriere/data/packages/<your-build-name> like: % ls -lad .latest lrwxr-xr-x 1 root wheel 16 Nov 10 12:07 .latest@ -> .real_1541851673 Changing that link to point at an earlier version of the repository will achieve the effect you desire, although be aware that poudriere will tend to update it to point to the lasted build results each time it is ru= n. > 3. When a package doesn't build because of a patch error: >=20 > =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 >=20 > Is this a problem with the ports tree, the upstream package, or some > other package? In other words, can that problem be fixed without having= > an updated version of the port (e.g. assuming the upstream package or > the other package gets updated and rebuilding the same package without = a > new version of the ports tree may fix this). Are patches always kept in= > the ports tree or sometimes they may be kept separately (e.g. in anothe= r > repo versioned independently)? Patches that fail to apply cleanly is an obvious problem that port maintainers will deal with routinely at a very early stage whenever updating a port. Even if someone managed to accidentally commit a broken patch, it would generally be fixed in pretty short order. If you're seeing this frequently in your checked out ports tree then it's probably due to 3rd party patches you've added to the tree or old patches that have been deleted upstream but that somehow still exist in your checkout. 'svn status' or 'git status' will tell you about locally added files or various forms of tree conflict that prevent removing a no-longer-required patch. If you need to maintain your own set of private patches to the ports tree, that is certainly possible. I'd recommend uing git to clone the freebsd-ports repo and creating your own branch as that is probably the lowest effort way of being able to merge in upstream changes. Cheers, Matthew --NLQWEpMMScxieNvHpVNtUREIyeMdcGnPC-- --fxnYY8hyzuSWR0sdfqIbMjEuCGpFXmi1z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAlvoPDlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDE5 RjE1NEVDQkYxMTJFNTA1NDRFM0YzMDAwNTEzRjEwRTBBOUU0RTcACgkQAFE/EOCp 5Odg9w//cR31Z+RquUFk0NfFqIwvDhUL5sHGgPXL4Y3G/ns/8H7rnlmUsIbW7F/g eYKo7tWEShfdwwC1GydIzmbeqOS2EGWN64V/NyOv0Zd0a4QZrRXzJUXraK0dODH7 7knNkWPEZ8VtHZMiVzzC8Ae7rsriXU2HMnWh4REfawdP2ocT/jaK8tZGMSRxY04G F+hMwUAWvOoarIq1hwimmp07WXQ7g/LfXCn4Y1NGv/ICHcCZTD0QahrN7i3KL4Ma hlDQ09E5LAxQY9iq1AkAcj8ZWMN2v3xF8vKejUrLZQsNwWdR5jJ0tRcK8+0dhTdV pMrZskOx8S8k1U3gABlhbDWwVVJSDfJddDFkoYvFMCA7q0eBJ4UtDJbCoU9d4efY LwhDw/xVvEVJwufJ3UXEfIX0UwK5x8U0Szt8hyavg7Vf9G6msRy0tcRhCQ/mSqyw WDzj0eMXmAnckKIbA0zppm6F0kyuawJ/fPaWRylTlvivg984iQgSgxeeuD4wL6ey 62/eNWqTbLiXH77MyVDQkQDG0P89kseuIesWktUVbrxAI0xNgu2AdxBxNuRXzthO 4PrYMTAgpqudg5TRrIIBJv99jVHUtOToogA46Z1x2AbssQTkkmflh6Zprj/WmjH+ +MSROXu7/Qw3S41bywDiyz2MWONbu4PmDJ/hBjeV3q9Rj8yTzvs= =RIW9 -----END PGP SIGNATURE----- --fxnYY8hyzuSWR0sdfqIbMjEuCGpFXmi1z--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ea0d5d27-eacb-c5c9-c73d-6eaea2d6ab8e>