py-peewee: updated to 4.0.1
4.0.1
* Ensure `gr_context` is set on greenlet in `greenlet_spawn` so that
contextvars will be operable in sync handlers.
* Removed `SqliteExtDatabase` (it basically served no purpose in 4.0). Use
`SqliteDatabase` instead.
* Moved driver and extension-specific pooled implementations into the
corresponding extension module rather than putting all into `playhouse.pool`.
* Restore custom `dumps` option for postgres JSON fields.
* Major docs rewrite / reorganization.
Instead of hard-coding the ramdisksize both in the distrib makefiles
and the kernel, provide a script to grab the size from the kernel so
we can define it in one place.
Update security/py-trezor-agent to 0.13.0
Note: The version number is lower now because the version number was wrong
before. Although both libagent and trezor-agent are distributed in the same
tarball, the version name in the tarball name is only for libagent.
Update security/py-libagent to 0.16.0
- Test on Python 3.13 by @romanz in #492
- Support SSH CA generation by @romanz in #493
- replace pkg_resources for python 3.12 by @branchv in #480
- Dedup sending age response by @romanz in #497
- Parse SSH server host key as well by @romanz in #507
- Drop keepkey support by @romanz in #511
- Drop ledger support by @romanz in #513
- libagent: Add USB IDs for Jade Plus by @nitramiz in #510
- Switch to trezorlib 0.20 to support TS7 by @romanz in #512
Additionally, two patches have been applied on top of 0.16.0:
- Lookup GnuPG user ID (instead of assuming it's the first one) in #517
- Fix passphrase support on Trezor in #519
zfs: reject read() on directory
right now, netbsd in general allows read() on directory for
the compatibility with historical applications. (i have not
seen such an application by myself though. is anyone around
here still keeping such ancient binaries? i'm curious if such
a binary still works on today's UFS.)
this commit makes zfs reject such an attempt because zfs is
not prepared to produce the historical UFS dirent structure.
x86 tsc: decrease the timecounter quality for NVMM
NVMM vcpu loses its TSC "ticks" when switching to a different host cpu.
from the POV of the guest OS (ie. this code), it's observed as random
TSC drifts, which makes it unsuitable for a timecounter source.
sched_4bsd.c: honor the upper bound of l_estcpu
otherwise, certain threaded workloads can quickly
accumulate too large l_estcpu.
this change fixes mysterious long (eg 10 seconds) pauses
i've seen occasionally with git. git seems to spawn worker
threads internally these days and happens to hit the condition
of this bug. with very large l_estcpu, the lwp gets effective
priority 0 for a long time. on a busy system, such an lwp
basically will never get a chance to run until the estcpu decay
will eventually make it possible to run again.
it seems this bug has been there since 2007.
("Merge scheduler changes from the vmlocking branch")
at that time, while i had been using netbsd heavily for daily
things, i haven't noticed this issue at all. it seems that
threaded programs got ubiquitous in this decades.
zfs: fix data loss with some combinations of mmap and write
in write(), make a mmap page clean only when we are overwriting the
whole page. otherwise, modifications made via mmap which are outside
the overwritten region will be lost.
tested with https://github.com/yamt/garbage/blob/master/c/ubc/ubctest.c
zfs: fix a deadlock in read()
while zfs on netbsd is a non-UBC filesystem, we have a logic to try
mimicking UBC-like consistency between mmap and read/write, which
some "broken" applications might rely on. however, the logic is not
safe as indicated by the XXXNETBSD comment. it isn't safe because
touching user pages can involve page faults, which may need to block
on other (or even same) pages with an undefined locking order.
this commit fixes it by using an intermediate buffer to avoid touching
user pages while keeping a file page busy.
although this probably can be optimized by checking VV_MAPPED, i'm not
in a mood to complicate this already-complicated code further. because
zfs doesn't use UBC, if a file has uvm pages, it almost certainly has
VV_MAPPED anyway.
tested with https://github.com/yamt/garbage/blob/master/c/ubc/ubctest.c
[5 lines not shown]
solaris vfs_optionisset: treat 0 as unspecified
this allows users to leave it default.
before this change, when a user runs "zfs mount -a",
it was processed as "mount them read-write, overriding readonly property".
i don't think it's what the user usually intends.
looking at the illumos code, it seems that mount options there are
basically tri-state. that is, "ro", "rw", and unspecified.
as NetBSD only has a single bit, MNT_RDONLY or !MNT_RDONLY, this commit
maps !MNT_RDONLY to unspecified, which i believe more often matches
the user's intention. it also seems like what illumos does for the legacy
MS_RDONLY bit if i read their code correctly. that is, if MS_RDONLY is set,
it sets MNTOPT_RO. on the other hand, a lack of MS_RDONLY doesn't imply
MNTOPT_RW.
references:
"Temporary Mount Point Properties" section of zfs(8)
[3 lines not shown]
qgis: Adjust \todo in Makefile and TODO
The only significant change is a decision to create a default-off
option for qtwebengine, because it's beastly and I don't understand
how qgis with it does anything more useful.
