Re: gzimg hashes

On Sat, 18 Jul 2026 at 09:10:23 -0600, Brook Milligan wrote:
> > On Jul 15, 2026, at 16:51, Valery Ushakov
> <uwe%stderr.spb.ru@localhost> wrote:
> >=20
> > On Wed, Jul 15, 2026 at 11:54:46 -0600, Brook Milligan wrote:
> >=20
> >> Yes, indeed a parallelism issue.  That is now fixed.
> >=20
> > mkhashes still carries stale $NetBSD$ from its prototype
> >=20
> > mkhashes serializes image creation, can't we exploit make
> parallelism
> > istead of fighting it?
> >=20
> > foo.img.gz.$(HASH) depends on foo.img.gz
> >=20
> > $(HASH) depends on all *.img.gz.$(HASH) with a trivial cat $> > $@
> > rule
>=20
> Good point.  At first, I was trying to minimize the changes.  However,
> here is another solution along the lines you suggested.
>=20
> The basic idea is to add a new target (snap_md_post_images) to the end
> of snap_md_post that takes care of the (up to) four steps: (i) create
> an uncompressed image, (ii) create compressed bootable images +
> corresponding hash fiies from it, (iii) compress and hash the original
> image, and (iv) collect all the hashes into a single file.  Each step
> can be done in parallel, something that itself is an improvement.=20
> Also, all these steps are not necessary for every architecture, so
> some changes skip or merge these four into fewer.
>=20
> Please look over the patch below and provide comments.
>=20
> Thanks a lot.

I've found no issues with these running repeatedly over the past week or
so, at parallel jobs between 8 and 12. (I've run builds for evbarm-
earmv7hf, evbarm-aarch64, evbmips-mipsn64eb, evbppc, and riscv64.)

Thanks,

Dave