fast, lightweight, and generally good way for users to keep their
ports trees up to date.
This is version 0.9.4 from the ports tree (sysutils/portsnap) with
the following changes:
1. The experimental pipelined http code is enabled. No seatbelts
in -CURRENT. (^_^)
2. The working directory has moved from /usr/local/portsnap to
/var/db/portsnap (as discussed on -arch two days ago).
3. Portsnap now fetches a list of mirrors (distributed as DNS SRV
records) and selects one randomly. This should help to avoid the
uneven loading which plagues the cvsup mirror network.
4. The license is now 2-clause BSD instead of 3-clause BSD.
5. Various incidental changes to make portsnap fit into the base
system's build mechanics.
X-MFC-After: 6.0-RELEASE
X-MFC-Before: 5.5-RELEASE
X-MFC-To: RELENG_6, RELENG_5, ports
discussed on: -arch and several other places
"yes please" from: simon, remko, flz, Diane Bruce
thinks this is a great idea: bsdimp
Hopes he didn't forget any files: cperciva
the role of MAINTAINERS into advisory and strict parts. Introduce a
new LOCKS file to document enforced locked parts of the tree.
Strict locks are only added with core approval and will generally
have a renewal timeout.
Clarify that the source tree is a community effort, not a place to stake
out 'turf'.
This will be refined as needed.
With-core-hat-on: Yes
"inofficial" declarations of maintainership. Grep all plain files,
and insert the actual command the list was generated with, so
future updates avoid that pitfall.
Removed sheldonh@ who just released his maintainership of ntp/doc
after I informed him of this effort.
This class is used for detecting volume labels on file systems:
UFS, MSDOSFS (FAT12, FAT16, FAT32) and ISO9660.
It also provide native labelization (there is no need for file system).
g_label_ufs.c is based on geom_vol_ffs from Gordon Tetlow.
g_label_msdos.c and g_label_iso9660.c are probably hacks, I just found
where volume labels are stored and I use those offsets here,
but with this class it should be easy to do it as it should be done by
someone who know how.
Implementing volume labels detection for other file systems also should
be trivial.
New providers are created in those directories:
/dev/ufs/ (UFS1, UFS2)
/dev/msdosfs/ (FAT12, FAT16, FAT32)
/dev/iso9660/ (ISO9660)
/dev/label/ (native labels, configured with glabel(8))
Manual page cleanups and some comments inside were submitted by
Simon L. Nielsen, who was, as always, very helpful. Thanks!
maintenance given his work on USB. Also, the root cause of spamming da(4)
with NO_6_BYTE quirks was fixed last year and the extraneous quirks have
been removed. Please coordinate future quirk issues with sanpei@
and libdevstat, since the new way of doing things is to just list
maintainership in src/MAINTAINERS.
Also, remove duplicate entries in src/MAINTAINERS for those utilities. I
already had entries for them.
its own just fine. Nuke request for heads-up on libufs, most of my work on
it these days is gradual, and mention that I'm willing to help with work in
it, so that others can feel free to make it suck less, and get feedback from
me in a purely "I understand this crud" sort of way.
to run patches to make(1) by. Hopefully this will make it easier to get bugs
fixed in make(1), as well as get review by people with experience working on,
in, around, etc., make(1).
Currently it points to two people who have demonstrated maintainership (ru@
and myself) and one person interested in helping (alane@). That list is
subject to expansion and contraction.
the build. It is here to compartmentalise functionality currently duplicated
in many notable programs in the base system. It currently handles block
reads and writes, as well as reading and writing of the filesystem superblock,
and the reading/lookup of inode data. It supports both UFS and UFS2. I
will be maintaining it, and porting programs to use it, however for now, it
is simply being built as part of world.
Add a MAINTAINERS line for the regression module, specifically referring to
src/tools/regression/usr.bin, right now, but applicable to other things, to
make clear that I am willing to help write new tests. The framework is all
modularised now, so it is easy to write new tests, etc., and since I'd like
to see tests for more and more things as bugs get fixed, it seems to be the
right thing to do to stand up and offer to help people write tests.
I'm sick of waiting on OpenBSD to make a number of changes anyway. If someone
else wants to take over fixing m4(1), I'll be glad to make them aware of the
existing issues.
