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 <mark...@yahoo.com> Datum: zaterdag, 11 januari 2025 04:21 Aan: Ronald Klop <ronald-li...@klop.ws>, FreeBSD Mailing List <freebsd-po...@freebsd.org> 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
