daily CVS update output
Updating src tree: P src/doc/CHANGES P src/share/man/man4/lm.4 P src/sys/dev/ic/nslm7x.c P src/sys/dev/isa/wbsio.c P src/sys/dev/isa/wbsioreg.h P src/usr.sbin/sysinst/bsddisklabel.c P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/gpt.c P src/usr.sbin/sysinst/label.c P src/usr.sbin/sysinst/msg.mi.de P src/usr.sbin/sysinst/msg.mi.en P src/usr.sbin/sysinst/msg.mi.es P src/usr.sbin/sysinst/msg.mi.fr P src/usr.sbin/sysinst/msg.mi.pl P src/usr.sbin/sysinst/util.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 43655871 Dec 16 03:03 ls-lRA.gz
Re: /etc/protocols generation
Christos Zoulas wrote:
> Sounds good to me, perhaps something like
> src/etc/refresh-data/ with some structure under
> there?
I have a few scripts here:
https://www.netmeister.org/tmp/iana-data.tar.gz
Two questions:
1) Since this is solving the same problem using the
same input and producing the same output, the awk
scripts there resemble those from pkgsrc/net/iana-etc/
necessarily. Those, however, are released under the
Open Software License ("OSL") v. 3.0. I don't know
whether my scripts are sufficiently original to not be
considered derived work; if not, then we'd have to
import those scripts using the OSL.
This, then would speak in favor of leaving the tools
in pkgsrc. The Makefile could then perform the task
of reaching over into pkgsrc? Seems like a messy set
up and not much of a win. :-/
Or we'd re-write the tool without using awk and thus
avoiding the licensing issue, although that seems the
most intuitive tool for the job and another solution
may feel awkward?
2) I wanted to add the execution of the ATF tests, but
those literally test the outcome of the files
installed under /etc. For a full validation, one
would need to copy the generated file into /etc, which
seems heavy handed to me. Having a partial test that
may generate a diff when the file is updated seemed
reasonable to me.
Thoughts?
-Jan
Re: Branching for netbsd-10 next week
> Just to wrap up this thread: > - branch will probably happen in the next ~10h > - default file system for new installations will be FFSv2 > I will update docs and extend the wiki page about FFS2ea to show how to > switch later, and also provide installation instructions how to select > FFSv2ea right during installation (trivial to do, but better we have > something to be found for later searches). > Thanks to all the input provided on this list and off list! > Martin I will want to update my NetBSD installation from 9.99.82 from source and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up -dP -A" to update the source on base system and pkgsrc, currently am on native X. How will I be able to access (read-only OK) FFS2ea from NetBSD 9.99.82, and what about compatibility with FreeBSD regarding file system? I assume no compatibility with Linux. Will I have to worry about the entropy problem when building or updating packages from 9.99.82 to 10.99.1, or, less likely, 10.0_BETA? Has that been fixed? Tom
Re: Branching for netbsd-10 next week
Am 15.12.22 um 11:35 schrieb Martin Husemann: Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin Thanks Martin for keeping us up with the progress and the decision for the default file system. I think considering all the opinions expressed, this is a good decision. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: Branching for netbsd-10 next week
Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin
Re: HEADS UP: UFS2 extended attribute changes will be committed tomorrow
Hello Chuck, Am 05.12.22 um 16:32 schrieb Chuck Silvers: In my records, I noticed another note that I had made more than a year ago. That was around the time the Posix ACLs were imported into NetBSD. I'm not sure if this is on anyone's radar, or if it's generally considered a requirement. I would be interested to know how dump / restore are affected by the current changes, or if there are plans to add support for Extended Attributes / ACLs to them. Back in FreeBSD 6.0 times there was a patch[1] that did exactly that for the FreeBSD variants of dump / restore. Probably the source code deviates however far from it. christos applied the dump changes for extattrs from freebsd to our code last year: commit 52fea75266aee4480e62dd763d4d3d74b002ea5c Author: christos Date: Sat Jun 19 13:56:34 2021 + Add external attribute dumping and restoring support from FreeBSD. Does not fully work yet, attributes are being saved and restored correctly, but don't appear in the restored files somehow. there is a bug in that code that effectively prevents restoring NFSv4 ACLs. I have a fix for this bug that I need to apply to freebsd and then I'll apply it to our code as well. thanks for the update. I have seen the fix has landed in NetBSD code base earlier this week - great job! ACL support in NetBSD becomes more and more complete & solid :-) Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
