trimming_ignore poudriere failure

Hi,

I'm trying to get some more attention to the 'trimming_ignore' error in the pkg building cluster.

See latest 141releng-armv7-quarterly failure: https://pkg-status.freebsd.org/ampere1/.

The part of the logs about this error are not public (AFAIK). So could somebody with access take a look what is happening?

Regards,
Ronald.

 
Van: Mark Millard <marklmi-/[email protected]>
Datum: zaterdag, 11 januari 2025 04:21
Aan: Ronald Klop <[email protected]>, FreeBSD Mailing List <[email protected]>
Onderwerp: RE: pkg build FreeBSD:13:armv7_latest failing with trimming_ignore
> 
> Ronald Klop <ronald-lists_at_klop.ws> wrote on
> Date: Fri, 10 Jan 2025 08:23:53 UTC :
> 
> > Looking at https://pkg-status.freebsd.org/builds?all=1&type=package all builds for 'default' and 13[34]releng-armv7 are failing with status 'trimming_ignore'. This started on December 15.
> > I hoped it was a glitch but it keeps happening.
> >
> > Looking at https://www.klop.ws/pkgstats/pkg-age.html it is also obvious that FreeBSD:13:armv7_latest is a bit off. :-)
> >
> > Search for 'trimming_ignore' on the pkg-status page I saw that 141releng-armv7 and main-armv7 had this issue also once or twice, but a follow-up build succeeded.
> >
> > Does anybody have an insight on the cause (and solution) of this trimming_ignore state?
> 
> 
> I'll note that the first example of this is from back on 2024-Dec-03:
> 
> default quarterly 141releng-armv7 257d1c796954 0 0 0 733 1456 -2189 trimming_ignore: Tue, 03 Dec 2024 13:31:50 GMT 00:04:34 ampere1
> 
> That is: quarterly, 14.1, on ampere1
> 
> Not being all that old, it seems to be associated with some sort of fairly recent change.
> 
> The 2024-Dec-03 failure is 41 armv7 build attempts ago (if I counted right). It is one of the 8 such failures so far. So, usually the build attempts do not get this problem. (Racy failure?)
> 
> So far, there are examples of each of:
> 
> Quarterly: 13.3, 14.1
> Latest:    13.3, 13.4, main
> 
> An implication is that all 3 of ampere[1-3] have had it happen.
> 
> So, what changed that applies to all 3 ampere* machines?
> 
> An interesting oddity is the elapsed time's ranges over the 8 failures:
> 
> Shortest: 00:04:08
> Longest:  00:17:58
> 
> But looking at which machine separately:
> 
> ampere1 (so: quarterly):
> Shortest: 00:04:08
> Longest:  00:05:41
> 
> ampere3 (so latest --but not main)
> Shortest: 00:07:56
> Longest:  00:08:42
> 
> ampere2 (just one example for main, which is an example of latest)
> Shortest: 00:17:58
> Longest:  00:17:58
> 
> ===
> Mark Millard
> marklmi at yahoo.com
>  
> 
> 
>