community/*: rebuild with go 1.16.5

This commit turned the tree red! :(

Can we do a test build in the future on CI when rebuilding all the go packages somehow? Maybe we can make a side repo with very generous CI limits?

@clandmeter @Ikke what do you think?

Gitlab CI is rather painful to test such rebuilds. One failed package means that a job for given arch must be retried and all packages (even those that were previously green) must be build again. Because of it such pipelines block others for a very long time.

I'm actually surprised that this rebuild is troublesome as the builders for 3.14 were doing rebuilds very recently. I thought that such security fixes have a priority and we want to have them in 3.14. That's why I went for it. Correct me if I'm wrong.

Ok, looks like 3.14 is all green now. I'm working on the testing repository.

I won't have much time today to handle more build failures but it's mostly about Go modules. docker-credential-ecr-login needs manual intervention on the builders or setting chmod-clean in options. It wouldn't be such a chore now if security rebuilds for Go have been strictly followed. Last time it was done by @Ikke a year ago (ea04c3a7) so unfortunately some aports are a bit stale. Perhaps it's a good time to move some to unmaintained.

Right, please don't take my comment as a complaint, more like a request that we brainstorm a better way to handle these in the future. This is more a note to myself to be an item to bring up at our first TSC meeting in a few weeks.

Thanks for handling the security update, of course.

Well, sorry for not handling this right away. I unexpectedly got distracted by life. Thanks for helping with it (not life, the builder issues ).

As for the meeting I think a test infra where Alpine devs could spin up lxc containers would be very useful. There are times when I can't reproduce the issues present on the builders (e.g. !21039 (comment 157663)). Not to mention that qemu emulation on my machine is slow as hell.

Maybe we can make a side repo with very generous CI limits?

The limits are mostly hardware related. We limit the amount of concurrent CI builds to 2 per runner, so having a side repo does not change anything to that. For certain arches we could probably spin up more runners, but not for all arches.

In the meantime, I'm working on fixing zabbix-agent2-alpine, which failed.

As for the meeting I think a test infra where Alpine devs could spin up lxc containers would be very useful. There are times when I can't reproduce the issues present on the builders (e.g. !21039 (comment 157663)). Not to mention that qemu emulation on my machine is slow as hell.

Developers can request lxc containers on our build infra. Easiest if you could hop by on #alpine-infra on irc.oftc.net.

Will do when the need arises, thanks for the info.