In D34788#788463, @karels wrote:

Am I allowed/able to commit this with only a src commit bit, or can someone else do it?

In D34746#788407, @dch wrote:

In D34746#788403, @gjb wrote:

It is entirely too late for this to be added for 13.1.

Let's wait until 13.1 is done, so I can properly allocate the time to test.

Absolutely! I'm still working on docs & testing myself.

It is entirely too late for this to be added for 13.1.

In D29923#786580, @gjb wrote:

In D29923#786579, @emaste wrote:

Just ran into this again (while doing some investigation related to f90cd1ae30b5f49e9f6ea58a0628ce1c8d8822bc) - looking forward to when these get added.

Yeah, this has been on my todo list for some time, and I finally had some time to look into this over the past two or so weeks.

There are two simultaneous problems here:

• There is no equivalent to 'make -C /usr/src/release ftp' for arm, only for "big iron" platforms (arm64 included to a point).
• There is no way to easily differentiate some of the older stable branches u-boot version (i.e., sysutils/u-boot-rpi versus sysutils/rpi-firmware, and quite honestly, I have lost track of what gets installed where and on which branch at this point).

That said, it is not necessarily a 'release.conf' issue, but the issue that 'src/release/Makefile' does not have an 'ftp' equivalent target for creating the .txz distribution sets for armv6,armv7. And after poking around at release/Makefile*, I honestly cannot remember how the hell the arm64/aarch64 FTP (base.txz, kernel.txz, etc.) sets are created.

I may need some sleep and/or some liquid courage to back-track through the arm64/aarch64 FTP dist sets and into how to properly create them for armv6,armv7.

In D29923#786579, @emaste wrote:

Just ran into this again (while doing some investigation related to f90cd1ae30b5f49e9f6ea58a0628ce1c8d8822bc) - looking forward to when these get added.

Another thought just came to me: what happens when the ZFS version on the builder differs from the target version? Out of conservatism, I try to only upgrade the builders when necessary (such as a new syscall being added, etc.).

In D34426#783433, @markj wrote:

Ping, any other comments? The pool version issue is worth addressing in some way but isn't a blocker IMO. Ideally we could start publishing ZFS snapshots for 14.0 as quickly as possible to start collecting feedback and bug reports ahead of any official support for these images.

In D34426#780015, @gjb wrote:

Please give me a few days to review the rest of this. I would like to expand this beyond cloud images, i.e., the files populated in the VM-IMAGES directory on the download mirrors, which will require adjustments to Makefile.mirrors.

Please give me a few days to review the rest of this. I would like to expand this beyond cloud images, i.e., the files populated in the VM-IMAGES directory on the download mirrors, which will require adjustments to Makefile.mirrors.

In D33999#779094, @jrtc27 wrote:

In D33999#779087, @gjb wrote:

My apologies, I forgot to respond to this review request earlier.

Since we do know !NO_PKG does not necessarily work yet, please go ahead and commit to main, but do not MFC to stable/13 until we have that particular area resolved, since we are in the 13.1-RELEASE cycle phase now.

Wasn't planning to MFC it anyway due to the potential disruption to stable branch image building, even aside from the current release cycle, though you're of course welcome to do so at any point that's convenient for you. Do you want to also check over the other smaller patches in the stack (specifically D33998 and D34001 for things that touch release/)? Nothing hugely interesting in those, this is the main one.

My apologies, I forgot to respond to this review request earlier.

In D34134#771926, @trasz wrote:

Btw, it would be nice if we could provide a direct link to amd64 14-CURRENT memstick image, but the filenames contain git revisions, so it's a bit impractical. Perhaps we could have a symlink?