Please see: D56118.

In D56117#1283524, @ivy wrote:

that sounds reasonable. note this blocks D56087, so i'm interested in the result.

Give me some time to test it, but I think it is better if we just update share/mk/src.opts.mk (and regenerate the manual page afterwards):

.if ${MK_BLOCKLIST} == "no"
MK_BLACKLIST:=	no
.endif

In D56070#1283471, @ivy wrote:

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.

edit: this is partly why i suggested using .export instead of editing the pkg commands.

Thank you! It works well now (overall). There are a couple of things that fail on aarch64 (described inline). Other than that, this is great. Thank you!

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282790, @ivy wrote:

@jlduran, @imp: this may impact what you're working on for nanobsd.

In D56070#1282531, @ivy wrote:

i have a strong preference for using SOURCE_DATE_EPOCH here, if possible: it will avoid conflicting with some other pkgbase work i'm doing, and more generally seems like a cleaner solution as anything that needs that can easily consume it; this is information that should be generally available to the build system.

In D56070#1282516, @kevans wrote:

Specify the modification time (mtime) of the files to match SOURCE_DATE_EPOCH rather than the current time when creating packages.

Can you spell out a little more clearly in the commit message why pkg's automatic SOURCE_DATE_EPOCH usage isn't sufficient here, please? By all accounts it seems like this should be a nop, so I guess it's that SOURCE_DATE_EPOCH isn't exported into pkg's environment in these targets?

In D56013#1281115, @ivy wrote:

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

i don't think this is right (and based on what i remember of mtree-to-plist, i'm not sure it'll even work). /boot should be owned by the bootloader package; if something is adding a package=utilities tag to it, whatever's doing that should be fixed.

• Previous revision stack was committed.
• All possible improvements that derive from this file, will be re-submitted.

In D55651#1274046, @ziaee wrote:

See ls for similar language.

Thank you! For taking the time to translate the handbook.
I just glanced over and found this minor nit.
I wonder why backup server is no translated as servidor de respaldo.
Servidor de reemplazo to me sounds like replacement servers.

• Add --libxo to usage message

Address suggestions:

• Do not manually reclaim memory

Refactor chunk of code:

• Prefer clear, separate if statements
• sizeof(char) is always 1

In D55610#1272421, @des wrote:

In D55610#1272406, @jlduran wrote:

Note that we want to keep the current behavior in makenetvfslist().

Why?

Note that we want to keep the current behavior in makenetvfslist().

Address suggestions.

Rebase

Address suggestions

I wouldn't use the word "Fix", they are both correct. "Standardize" perhaps?

Note that I would have "accepted" the previous version if it wasn't for Eugene's remark. I can try adding a simple test that checks it is warning and not erroring when parsing a configuration file if you believe it is necessary.
Regarding the missing EOLs in the dprintf()s, I see those are no longer present, evidently the message needs updating upon commit.

• Rebase

• Implement a strsuftoll(3)-compatible function, as the value of NANO_SLICE_FAT_SIZE should be compatible with makefs(8) -s.

• Add more occurrences

• Update the comment to indicate that we also remove the time keyword