devel/py-cclib: Update 1.7.1 -> 1.8.1
- Switch to the PyPI since upstream moved to pyproject.toml with
versioningit
- Switch from distutils to pep517
- Add new runtime dependencies: packaging, periodictable, scipy
- Add concurrent (installs console scripts) and NO_ARCH
- Refresh pkg-descr
Sponsored by: https://watchgoose.com
net/samba425: restore missing FreeBSD mDNS/dns_sd support (MDNSRESPONDER)
Same gap identified for net/samba424: three FreeBSD-local patches
providing dns_sd/mDNSResponder support (present identically in
net/samba419, 420, 422, and 423) were missing, gated behind the
non-default MDNSRESPONDER port option (default is AVAHI).
- source3/wscript/wscript_build: restore the --enable-dnssd waf
option (dns_sd.h/DNSServiceRegister detection, WITH_DNSSD_SUPPORT
define, dns_sd library linkage into smbd_base and smbclient).
Regenerated against the real samba-4.25.0 upstream source (which
has diverged from 4.24.7 in these two files, e.g. ceph rgw and
rate-limiting daemon additions) rather than copied verbatim from
samba424.
- source3/smbd/dnsregister.c: restore the FreeNAS-authored mDNS
advertise-per-interface fixes. This file is byte-identical between
4.24.7 and 4.25.0 upstream, so the samba424 patch applies verbatim.
- Makefile: MDNSRESPONDER_CONFIGURE_ENABLE=dnssd.
[9 lines not shown]
net/samba424: restore missing FreeBSD mDNS/dns_sd support (MDNSRESPONDER)
Three FreeBSD-local patches providing dns_sd/mDNSResponder support
(present identically in net/samba419, 420, 422, and 423) were silently
dropped when net/samba424 was created, all gated behind the
non-default MDNSRESPONDER port option (default is AVAHI):
- source3/wscript/wscript_build: the --enable-dnssd waf option
(dns_sd.h/DNSServiceRegister detection, WITH_DNSSD_SUPPORT define,
dns_sd library linkage into smbd_base and smbclient) never existed
in samba424 at all.
- source3/smbd/dnsregister.c: the FreeNAS-authored mDNS
advertise-per-interface fixes. Only the companion
source3/client/dnsbrowse.c half of this combined patch survived
into samba424; the dnsregister.c half was lost.
- Makefile: MDNSRESPONDER_CONFIGURE_ENABLE=dnssd, so selecting the
MDNSRESPONDER option actually passes --enable-dnssd to waf.
Without all three, selecting MDNSRESPONDER builds without functional
[10 lines not shown]
stress2: Add a new FS type: UFS2 to the test.
Workaround for kern.maxfiles limit exceeded.
Workaround for SU disk full issue.
Added some debug info, if umount(8) returns EBUSY.
databases/mongodb80: restore python 3.14 support
This always regresses after a big update. Sorry Peter :-)
Peter also added Bazel --batch mode. Explanation for batch mode
is in a comment in the Makefile and in the PR.
PR: 298510
games/openbve: update OpenBVE port to version 1.14.1.2
Garbage-collect no longer useful .Net version patching
for compatibility with deprecated Mono 5.10. Upstream
solution was updated as a whole to require .Net 4.8 in
version 1.14.0.2 onwards, which works fine against our
default Mono 5.20.
Reported by: portscout
ufs: do not let a rolled back inode write end a data-only sync
With soft updates, ffs_syncvnode() writes the inode between its passes
while buffers are still dirty. That write can go out with new block
pointers rolled back, for instance a new indirect block whose contents
are only written in a later pass, yet ffs_update() clears IN_SIZEMOD
and IN_IBLKDATA because the write was synchronous. A data-only sync
then decides at the end that the inode need not be written, and
fdatasync(2) or an O_DSYNC write that allocated the first indirect
block returned with the on-disk inode not pointing to it.
Note on entry whether a data-only sync has to write the inode, and base
the final write, done once all dependencies are flushed, on that alone:
nothing else can set IN_SIZEMOD or IN_IBLKDATA meanwhile, as the vnode
is locked. A full sync always writes the inode last and was not
affected.
Sponsored by: Sippy Software, Inc.
Reviewed by: kib
[3 lines not shown]
tests: add UFS synchronous write durability tests
Check that once fsync(2), fdatasync(2), or a write(2) with O_SYNC or
O_DSYNC returns, the new data, the file size and every block pointer
leading to the data are on disk. The cases append a block, fill a hole,
append the first block that needs an indirect block and append below an
existing indirect block. Two more append after another write left a
new direct block unsynced, which with soft updates cuts the size and the
later pointers of an inode written meanwhile. With O_SYNC and O_DSYNC
on soft updates, those also check that the open already made the
unsynced block durable.
Each case runs on UFS without soft updates, with soft updates and with
SU+J.
The file systems live on md(4) and the checks read the inode, the
indirect block and the data block straight from the device with libufs
right after the synchronous call returns. There is no cache in front
of the disk device, so this shows what would survive a crash at that
moment without having to crash anything.
[6 lines not shown]
ufs: make fdatasync(2) and O_DSYNC writes update the inode
ffs_syncvnode() in the DATA_ONLY case and ffs_write() for IO_DATASYNC
decide whether the inode has to be written by testing IN_SIZEMOD and
IN_IBLKDATA against ip->i_flags, the chflags(2) word, instead of the
in-core state ip->i_flag. IN_SIZEMOD and IN_IBLKDATA alias UF_READONLY
and UF_ARCHIVE, so for ordinary files the test was always false: after
an fdatasync() or an O_DSYNC write that extended a file or filled a
hole, the data blocks were on disk but the inode size and block pointers
were not, and a crash before the syncer got to the inode lost the
"synced" data. Files with uarchive or urdonly set got a synchronous
inode write on every call instead.
journal_mount() has the same mixup and sets IN_MODIFIED in i_flags,
which leaves UF_OPAQUE set on the in-core .sujournal inode. The
synchronous ffs_update() that follows writes the inode regardless, so
only the stray flag is fixed here.
Fixes: 7428630b757 ("UFS: write inode block for fdatasync(2) if pointers in inode where allocated")
[9 lines not shown]
ufs: flush soft updates dependencies for O_SYNC and O_DSYNC writes
For a synchronous write, ffs_write() writes the data buffers with
bwrite() and then the inode with ffs_update(vp, 1). With soft updates,
a new block pointer can only reach the disk after the dependencies of
the block, such as the cylinder group map that allocates it, are
written. Until then initiate_write_inodeblock_ufs[12]() and
initiate_write_indirdep() roll the pointer, and for an extending write
the size, back in the buffer being written. Nothing in the write path
flushes those dependencies, so the inode went out with the old size and
pointers, ffs_update() cleared IN_SIZEMOD and IN_IBLKDATA, and a crash
before the syncer rewrote the inode lost data that O_SYNC or O_DSYNC
promised was on stable storage. The same held for a new block below an
indirect block, which ffs_balloc() writes synchronously but with the
pointer rolled back.
When soft updates are enabled and the write allocated blocks, finish it
with ffs_syncvnode(), as fsync(2) and fdatasync(2) do: it flushes the
dependencies, rewrites the rolled back indirect blocks and writes the
[30 lines not shown]
ufs: make fdatasync(2) write dirty indirect blocks
A data-only ffs_syncvnode() skips dirty indirect blocks on file systems
without soft updates, and with soft updates stops making passes once
only indirect blocks are left dirty. Indirect blocks only get dirty
when the block pointers in them change, and those pointers are what
makes a newly allocated block reachable. So when fdatasync() follows
a write that extended the file or filled a hole past the direct blocks,
the data and the inode size reached the disk but the pointer to the new
block did not, and a crash lost the "synced" data. With soft updates
the indirect block was usually written once, with the new pointer
rolled back, and never rewritten.
POSIX requires fdatasync() to write the metadata needed to retrieve the
data, which 52488b51489 already acknowledged for the inode, so treat
dirty indirect blocks the same way for a data-only sync as for a full
one. This restores the loop to what it was before 2f514f92cf0. Plain
overwrites, the case data-only sync is meant to speed up, do not dirty
indirect blocks and still write neither them nor the inode.
[8 lines not shown]
