Re: git for armv7

From: Mark Millard <>
Date: Sat, 06 May 2023 20:33:30 UTC
On May 6, 2023, at 13:11, Mark Millard <> wrote:

> On May 6, 2023, at 12:40, Miroslav Lachman <> wrote:
>> On 04/05/2023 04:32, bob prohaska wrote:
>>> On Wed, May 03, 2023 at 12:38:58PM -0700, Mark Millard wrote:
>>>> bob prohaska <> wrote on
>>>> Date: Wed, 03 May 2023 18:43:09 UTC :
>> [..]
>>>> The old git package stuck around until the
>>>> distribution of the packages from the first
>>>> failure to build libunwind made it to the
>>>> download servers.
>>> Ahh, that makes sense. Old packages have too
>>> much baggage 8-) for the public servers.
>>> What happens in the case of a local poudriere
>>> repository? If it once builds a package, which
>>> subseqently fails, is the successful build
>>> deleted?
>> I would like to recommend some settings for local builds in poudriere.conf
> For reference, the commented descriptions from poudriere.conf.sample :
> # The repository is updated atomically if set yes. This leaves the
> # repository untouched until the build completes. This involves using
> # hardlinks and symlinks. The operations are fast, but can be intrusive
> # for remote syncing or backups.
> # Recommended to always keep on.
> # Default: yes
> # When using ATOMIC_PACKAGE_REPOSITORY, commit the packages if some
> # packages fail to build. Ignored ports are considered successful.
> # This can be set to 'no' to only commit the packages once no failures
> # are encountered.
> # Default: yes
> So this is where the difference vs defaults is.
> (But the two do operate as a pair for the result
> being referenced.)
>> These are very useful if you want a working repository for your machines every time you run "pkg install" or "pkg upgrade". Nothing is more frustrating than trying to build an update in Poudriere and it fails, leaving you with a broken repository. That's why we use atomic yes and don't commit on failure.
> Agreed: Anyone biased toward an all-vs-no-update
> status being a good thing should likely set this.

Lets see if I can actually express a complete thought:

Anyone biased toward an all-vs-no-update status being
a good thing should likely set COMMIT_PACKAGES_ON_FAILURE
to "no".

> (It just happens to not be what I normally want.
> But my context is odd.)
>> It changes slightly what Mark Millard described - Poudriere does not remove packages from your repository before building. It does it on a separate copy of the repository that is only used for the bulk build, and if it fails, your real repository remains untouched.
> Technically, ATOMIC_PACKAGE_REPOSITORY always uses a separate
> .build tree (name from memory), no matter the
> COMMIT_PACKAGES_ON_FAILURE setting in use. This allows not
> messing up the active repository for power outages and the
> like. COMMIT_PACKAGES_ON_FAILURE is about what to do once the
> bulk builder's have no more to do (just when it gets that far).
> If a .build is not committed to active, the next bulk build
> will use the .build's partial build as a starting point instead
> of starting from scratch. poudriere produces a message about
> that when it happens as I remember.
> This reuse can help avoid unnecessary rebuild time until there
> is no failure and a commit happens.
>> If you want to keep older repositories, you can set the following variables (we keep 3)

Mark Millard
marklmi at