On Jan 23, 2025, at 17:51, Mark Millard wrote:
> On Jan 22, 2025, at 21:02, Mark Millard wrote:
>
>> On Jan 20, 2025, at 16:17, Mark Millard wrote:
>>
>>> On Jan 17, 2025, at 21:00, Mark Millard wrote:
>>>
On Jan 17, 2025, at 10:19, Mark Millard wrote:
> On Jan 17, 2025, at 07:03, Mark Linimon wrote:
>
>> On 01/17/2025 3:41 AM CST Ronald Klop 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.
134releng-armv7-quarterly also built rust-1.83.0 just fine,
over 06:10:07 . So 4000+ more packages may end up having an
attempted build --finally.
===
Mark Millard
marklmi at yahoo.com
