Re: Poudriere: when fetching a package with porttree from a git source, the generation of logs is slow

Hello.

On 2026/04/10 12:15, Mark Millard wrote:
> On 4/9/26 02:26, Tatsuki Makino wrote:
>> As stated in the subject, it is slow :)
>> For example, the following log will be generated at the beginning.
>>
>> build started at Thu Apr  9 08:38:58 UTC 2026
(omit)
>> Port dir last git commit: b01ea745e968cda7c20fab0502c5119bdf533fb4
>> Port dir unclean checkout: no
(omit)
>>
>> Among these logs, the 'Port dir last git commit' line may take time to
>> obtain the commit hash, but it does not necessarily match the package
>> that was fetched when it was built.
> 
> My understanding was that when the ports tree ( /usr/ports/ above ) does
> not match the upstream version that can be fetched, including for any
> dependency mismatches or option mismatches, poudriere uses the the port
> tree based source to do that package's build --instead of installing and
> using the mismatched upstream build.
> 
> Presuming that for the below . . .
> 
> Testing if there is a match vs. not could involve checking for local
> changes: "Port dir unclean checkout: yes" would indicate a mismatch that
> would avoid using a mismatched fetch.
> 
> (The command used to do the bulk build was not shown so I could not
> reference it. If I've made bad assumptions about it, let me know.)

First, by publishing the packages created by poudriere on a local web server, the local poudriere can reuse those packages with another build set using the -z option.
My poudriere still automatically applies patches for modifications, so I am not sure if the official poudriere will operate correctly with that behavior.
In cases like this, where packages are mixed in that I don’t know when or how I created, and which may possibly have been created from portsnap source porttree, the commit hash obtained from git source porttree merely happens to coincide with the timing when a package of the same version was created.

In the case of other remote official upstream packages, for example, after successfully building a package for the x86 architecture, the addition of patches necessary to successfully build for the ARM architecture is accomplished through your significant contributions :)
In such cases, there are occasionally commits where the package version has not been bumped, possibly because it is a part that is not read during building on the x86 architecture.

There may also be cases where the git commit hash changes while the package version remains the same, such as when making modifications to the Makefile that are unrelated to the contents of the package.

Therefore, it seems that there is no need to run the process to obtain the git commit hash in the logs when fetching a package.

Regards.