From nobody Fri Jan 17 09:41:20 2025 X-Original-To: freebsd-pkg@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YZF9c0WQMz5kkjF; Fri, 17 Jan 2025 09:41:24 +0000 (UTC) (envelope-from SRS0=+oX9=UJ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YZF9Z4JCZz3Dn4; Fri, 17 Jan 2025 09:41:22 +0000 (UTC) (envelope-from SRS0=+oX9=UJ=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ZfH2GDrY; spf=pass (mx1.freebsd.org: domain of "SRS0=+oX9=UJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=+oX9=UJ=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Fri, 17 Jan 2025 10:41:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1737106880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2AghYV7mwvkxazKpvzHxG6H7SU489M55azOC8UHe3/w=; b=ZfH2GDrYE9Dr/h5bJ7tea2Fs1Oap8ni+nHIBDT81mci1hbw9pHFmWXVgCzbm7k+lVsRoOo noheItAZfSnt5y9oP8z2liCw36nq9mtra6qjlSCoRrfiVk+BQbLtsxkHGCXshSZAuELQGp zU9wvyWTKwDemE2CSPEgh32wBCQ36MX8RND1XeieLUelDj2B2di3d6PYBKs+QS/5ReAnag FaAASJNh2Ma3JpqgBjZaemSRcdCf8y9JODa2vURFXcHjDkHnxn4oi47BZvOuwZq9MZWhOc QHLii3PuMpRzWq+b1tzpbQtD9jqzHTDLS2ZmAYlsjx/45szd9pgirVaKM3D9qg== From: Ronald Klop To: freebsd-arm@freebsd.org, freebsd-pkg@FreeBSD.org Cc: FreeBSD Mailing List Message-ID: <1710947431.3032.1737106880170@localhost> In-Reply-To: <4226686C-BADB-4D9D-9CF9-54C3AF1692EB@yahoo.com> References: <4226686C-BADB-4D9D-9CF9-54C3AF1692EB.ref@yahoo.com> <4226686C-BADB-4D9D-9CF9-54C3AF1692EB@yahoo.com> Subject: trimming_ignore poudriere failure List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3031_634390530.1737106880068" X-Mailer: Realworks (734.117) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-4.09 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[194.109.157.24:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-pkg@FreeBSD.org,freebsd-ports@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=@realworks.nl]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_X_PRIO_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_FROM(0.00)[oX9=UJ=klop.ws=ronald-lists]; DKIM_TRACE(0.00)[klop.ws:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4YZF9Z4JCZz3Dn4 ------=_Part_3031_634390530.1737106880068 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Datum: zaterdag, 11 januari 2025 04:21 Aan: Ronald Klop , FreeBSD Mailing List Onderwerp: RE: pkg build FreeBSD:13:armv7_latest failing with trimming_ignore > > Ronald Klop 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 > > > > ------=_Part_3031_634390530.1737106880068 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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@yahoo.com>
Datum: zaterdag, 11 januari 2025 04:21
Aan: Ronald Klop <ronald-lists@klop.ws>, FreeBSD Mailing List <freebsd-ports@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
 

  ------=_Part_3031_634390530.1737106880068--