Description looks good.

EFI RTC works on 96-core arm64 ThunderX with this change.

@andrew committed a different fix.

For now avoid setting the reproducible build timestamp in PKG_ENV for all ports that set USES=python

Would it be reasonable to scan the plist for any port that sets USES=python, and avoid overriding the package archive metadata if any .pyo/.pyc found?

Debian doesn't ship the .pyc / .pyo files; they generate them at install time.

No objection from me.

A similar change has been committed

D13155 / rS326097 introduced a conflict; this needs a rebase.

What would you suggest for selectively setting PKG_ENV (e.g., for all but python ports, for now)?

• Bump default timestamp to nice round 1500000000 since it s no longer a future time
• Set SOURCE_DATE_EPOCH only for the pkg env, not the build env
• Add a comment

I approve based on @manu's review

I would put it before Differential Revision: to help cement the idea that D-R should go last (even though you'd generally not have both of these on the same commit) and because Differential Revision: is too long and pushes the rest of the text over to the right.

https://github.com/emaste/freebsd/commit/1847c866134eff8524004bdb2edeb457bf33a06e

Tested successfully on SoftIron OverDrive 1000 after applying fpu_kern_enter fix from @andrew via IRC

Mentor approved after @manu's review

After @manu's review, you have my approval.

I believe that the patch was already tested on arm64, IMO amd64 would be much more interesting.

Attempting to set the time on OD1000:

root@od1000:~ # date 1711171600
timeout stopping cpus
panic: invalid fpcurthread
cpuid = 2
time = 1510952400
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff00000060d8f8  lr = 0xffff000000086eec
         sp = 0xffff0000e64e93e0  fp = 0xffff0000e64e95f0

In D10486#273287, @cem wrote:

@emaste , @kaiw , any objection to committing this change?

I'm building a new kernel to test this on a SoftIron OverDrive 1000 now.

Ok, no objection to this patch.

Because we use the new newfs with the old kernel in the release process

I think this change is good (modulo kib's comment).

In D12765#272641, @imp wrote:

Won't this trigger every single time we build a snapshot with a kernel that doesn't match?

• fix stray ; \
• add explicit LC_COLLATE=C per @bapt suggestion

In D13103#272413, @bapt wrote:

You should enforce a locale for sort to produce a consistent output! either LC_COLLATE=C or anything (imho the best is LC_COLLATE=C)

I would put the 64-bit fields first, and make the whole struct 8-byte aligned, but I'll defer to any suggestion kib might offer.

As long as the ports tree is good let's get this back in.

In D13018#272087, @kib wrote:

The problem which I envision is that the uint64_t type has 8-bytes alignment on amd64, but only 4-bytes on i386.

How many warnings of this type does the build produce?

Also for the commit message -- it's not freeing that we need to avoid, it's using the null pointer at all. free(NULL) is actually fine. it's the printf/setenv that we can't pass a NULL pointer to.

undo accidental if_getdrvflags breakage

In D13015#270388, @kib wrote:

Aren't they automatically re-generated by somebody else ? I did found them by grepping, and decided not to update because they are not human-editable. Am I wrong ?

There are also adjustments to make in targets/pseudo/hosttools/Makefile.depend.host and targets/pseudo/userland/Makefile.depend