---
This is untested, but I wanted to check with Nathaniel to see if this
patch is closer to what he was thinking about on IRC yesterday.

 setup-disk.in | 103 +++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 80 insertions(+), 23 deletions(-)

diff --git a/setup-disk.in b/setup-disk.in
index 5eb8638..6e022d9 100644
--- a/setup-disk.in
+++ b/setup-disk.in
@@ -79,6 +79,26 @@ enumerate_fstab() {
 		done
 }
[message trimmed]

On Sat Jan 18, 2020 at 1:13 AM, Timo Teras wrote:
> Are there any more detailed requirements you might have?

No, at this point I'm mostly objecting on philisophical grounds and a
suspicion that this is going to restrict us more than it helps us in the
future.

> And do you think it should be possible to clone alpine/edge/community
> and rename it to "mynewlinux/x.y-stable/main" without resigning?

Sure, why not? What if I want to construct a new repo out of packages
cherry-picked from elsewhere? What if someone wants to support an
alternative release model for Alpine?

On Sat Jan 18, 2020 at 12:19 AM, Timo Teras wrote:
> > Still NACK on signing the repo name. Signed data should be autonomous
> > of its original source, so long as it's signed it doesn't matter how
> > it got to you.
>
> Would you be able to give some reasoning, arguments or use-cases why
> you think this is the correct approach?

The whole point of cryptographic signing is to be able to move packages
over an untrusted medium without ill effect. Should we also sign the
mirror URL? I don't think so. What if someone wants to stand up a new
mirror, do they really need us to intervene and agree to set up a key
for them?

This imports the package we made for sr.ht monitoring, which is more in
line with the design of prometheus-related packages in community.
---
v2 populates version information that was lost from the Makefile and
updates the default bind to 0.0.0.0.

 testing/prometheus-node-exporter/APKBUILD     | 59 +++++++++++--------
 .../disable-go-race-detector.patch            | 33 -----------
 .../node-exporter.confd                       |  7 ---
 .../node-exporter.initd                       | 22 -------
 .../prometheus-node-exporter.confd            |  4 ++
 .../prometheus-node-exporter.initd            | 13 ++++
 .../prometheus-node-exporter.pre-install      |  8 +--
 .../prometheus-node-exporter.pre-upgrade      |  1 -
[message trimmed]

On Fri Jan 17, 2020 at 9:31 AM, Timo Teras wrote:
> Having said all this. I am still somewhat concerned and thinking that
> putting repository name to the package might be useful thing. But
> perhaps in should be the originally-built-from-repository and not the
> index name.
>
> Does any of you share my concerns that the repo name should be signed?

Still NACK on signing the repo name. Signed data should be autonomous of
its original source, so long as it's signed it doesn't matter how it got
to you.

The package should be tagged in world, so if that tag is unavailable
perhaps we can just print a warning on apk operations listing packages

On Wed Jan 15, 2020 at 7:54 AM, Tiago Ilieve wrote:
> - Doesn't the patch make sense anymore? I've not been following the
> state of Go race condition check in musl lately.

That patch affects the makefile, which is now not used.

> - Does it make sense to drop the version information from the binary?
> I'm inferring that, as the software is being installed by a package
> manager, you are considering this information to be irrelevant.

We can update this to specify the version information in a manner
similar to how the prometheus package does it. Good point for v2.

> - If the binary name is being changed, why opt for

On Thu Jan 16, 2020 at 3:42 PM, Natanael Copa wrote:
> That is how current apk works, and is part of reason why it is
> significantly faster than other package managers. In general, when the
> other package managers are done with fetching the package and is about
> to start unpack them, apk is already done with it all.

"Move fast and break things" :)

> What apk does is that it extracts each file into a temp file without
> execute permissions until the signature is verified. If signature
> matches it renames all the files in one go, or deletes on failure.
> Rename and set permissions are very quick operation, while read/write
> all the data once again is not.

On Thu Jan 16, 2020 at 3:19 PM, Natanael Copa wrote:
> I think it as been mentioned before but I think it would be nice if we
> could have 2 operational install modes:
>
> - quick: in-the-air extraction/verification of packages (current style)
> - safe: store all packages locally and verify before trying to extract
> them
>
> safe mode is useful when the network connection is unreliable. In case
> of network error it could continue where it left off last time, rather
> than try fetch it all from scratch. Something like
> `apk upgrade --fetch-first` or `apk upgrade --safe`.

In my opinion, the "quick" mode is so unsafe that I find it really

Passing through all of the hardware from your host directly to the guest
negates the value of having a virt kernel in the first place, since at
that point the guest is hardly different from the host at all. You
should just use the stock lts kernel.

This imports the package we made for sr.ht monitoring, which is more in
line with the design of prometheus-related packages in community.
---
Tiago, what do you think of this approach? If you like it, let's take
these changes and move this package into community. I can also
adopt/maintain the package if you prefer.

 testing/prometheus-node-exporter/APKBUILD     | 49 ++++++++++---------
 .../disable-go-race-detector.patch            | 33 -------------
 .../node-exporter.confd                       |  7 ---
 .../node-exporter.initd                       | 22 ---------
 .../prometheus-node-exporter.confd            |  4 ++
 .../prometheus-node-exporter.initd            | 13 +++++
 .../prometheus-node-exporter.pre-install      |  8 ++-
[message trimmed]