Re: trimming_ignore poudriere failure [134releng-armv7-quarterly also failed, still no armv7 2025Q1 build in process]

On Jan 22, 2025, at 21:02, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 20, 2025, at 16:17, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Jan 17, 2025, at 21:00, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> On Jan 17, 2025, at 10:19, Mark Millard <marklmi@yahoo.com> wrote:
>>> 
>>>> On Jan 17, 2025, at 07:03, Mark Linimon <linimon@portsmon.org> wrote:
>>>> 
>>>>> On 01/17/2025 3:41 AM CST Ronald Klop <ronald-lists@klop.ws> wrote:
>>>>> See latest 141releng-armv7-quarterly (https://pkg-status.freebsd.org/ampere1/jail.html?mastername=141releng-armv7-quarterly) failure: https://pkg-status.freebsd.org/ampere1/.
>>>>> 
>>>>> The part of the logs about this error are not public (AFAIK)
>>>> 
>>>> The machine is only accessible by IPv6.  I have a 6 to 4 bridge running and
>>>> I was able to access them.
>>>> 
>>>> I have access to any bulk build logs and I expect Ronald does too.
>>>> that includes to:
>>>> 
>>>> https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/93a86df99a36/logs/
>>>> 
>>>> and to the the (here) empty:
>>>> 
>>>> https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/93a86df99a36/logs/errors/
>>>> 
>>>> The type of log showing any error information would not seem to be
>>>> port/package specific but more like what what should show the
>>>> poudriere commands themselves: logs from outside the builder process
>>>> instead of/from inside a builder process.
>>>> 
>>>> As for what can be seen from odd/incomplete content for logs for inside builder process . . .
>>>> 
>>>> There are several logs that are incomplete (all stop with
>>>> "---Begin Environment---") but that do not report any errors.
>>> . . .
>>> 
>>> An interesting point for almost all of the too-small log files
>>> (not for the one later example of a zero-size log) . . .
>>> 
>>> https://github.com/freebsd/poudriere/blob/3.4.2/src/share/poudriere/common.sh
>>> 
>>> has:
>>> 
>>> echo "---Begin Environment---"
>>> injail /usr/bin/env
>>> echo "---End Environment---"
>>> 
>>> which only has "injail /usr/bin/env" before the next echo
>>> and the /usr/bin/env output also did not show up either.
>>> 
>>> Some sort of racy "injail" failure specific to armv7,
>>> given the usual lack of failure?
>>> 
>>> Some sort of racy "/usr/bin/env" failure specific to armv7,
>>> given the usual lack of failure? (Possibly only for jail
>>> contexts?)
>> 
>> FYI: 134releng-armv7-quarterly for 93a86df99a36 also got a
>> failure that leads to "trimming_ignore:" being as far as
>> the status goes:
>> 
>> default quarterly 134releng-armv7 93a86df99a36 0 0 0 700 1291 -1991 trimming_ignore: Mon, 20 Jan 2025 21:39:37 GMT 00:04:14 ampere1
>> 
>> There are, again, a bunch of short logs that end just after:
>> "---Begin Environment---".
>> 
>> So, again it is going to be a notable time before armv7 gets a
>> 2025Q1 build, even if the eventual next *releng-armv7 build
>> attempt works.
> 
> 141releng-armv7-quarterly for 5db4fd43d478 is building. This will
> jump from failing to build rust-1.81.0 to trying to build
> rust-1.83.0 .
> 
> One property is that rust-1.83.0 internally uses llvm19 so anything
> that tries for llvm18 or before but also involves LTO and rust will
> likely fail. (LLVM vintage mixes tend not to work for LTO,
> especially based on older linkers getting involved.)

rust-1.83.0 built just fine over 06:21:37 . so 4000+ more
packages may end up having an attempted build for
141releng-armv7-quarterly --finally.

===
Mark Millard
marklmi at yahoo.com