only50000hoursif_bridge(4) on #freebsd 15 works a little different than the previous implementations. Assigning an IP address directly to the bridge interface is now the recommended thing to do. There are also pretty fine-grained ways to use and control VLANs on a bridge now. #callfortesting was where I heard about those changes first. Support https://www.youtube.com/@callfortesting on https://bsdfund.org, it’s super easy, took me less than a minute.
Peter N. M. HansteenCall for testing: Improved 802.11g AP compatibility check https://www.undeadly.org/cgi?action=article;sid=20250731111632 #openbsd #wifi #80211 #wireless #networking #callfortesting #freesoftware #libresoftware
Call for testing: bge/bnx/iavf/igc/ix/ixl/ngbe/pcn: ifq_restart() fix https://www.undeadly.org/cgi?action=article;sid=20250624072336 #openbsd #bugfix #current #callfortesting #test #bge #bnx #iavf #igc #ix #ixl #ngbe #pcn #networking #ifq_restart #ifconfig
@dexter well #callfortesting is a quite unique addition to the #FreeBSD related sources I consult and thanks to the participants all information is relevant and up to date. Choosing bhyve, jails and ZFS as the main areas of discussion makes it very efficient for me to consume information. However, I’m in a situation here and there where I’m about to follow up on something interesting I heard in the videos one or two weeks later but can’t remember which video it was. For instance, the person implementing VLAN tags directly into the bridge interfaces. I’m not sure if this justifies to introduce a more general catchall networking/general system administration category though. I guess I personally benefit from a reminder in the video description that minutes and most slides used are available on callfortesting.org because somehow I was not aware of the website and the Google docs up until yesterday 😀
Improved ACPI WMI support (may be) incoming https://www.undeadly.org/cgi?action=article;sid=20250511124600 #openbsd #acpi #wmi #hardwaresupport #lapops #powermanagement #callfortesting #libresoftware #freesoftware #unixlike #support
ティージェーグレェI was slackin!
Almost a week behind the Call For Testing for OpenSSH 10.0!
(OpenSSH UNIX dev mailing list archive message on such things here:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2025-April/041855.html)
Preliminary results on macOS 15.4 leveraging MacPorts are lookin good so far:
./ssh -V
OpenSSH_9.9p2-snap20250407, LibreSSL 4.0.0
Running %make tests
"all tests passed"
So that's great too!
Note: this version removes DSA support.
Previously, that had been omitted from default compilation options (though there were some squeaky wheel MacPorts folks who ended up contributing the legacy_dsa variant to toggle that compilation option back on; I'm trying to figure out the best way to give them a heads up that they're going to need to maintain a patchset diff from upstream if they want to keep that variant. For the time being, hopefully updating the Trac issue will at least notified interested individuals:
https://trac.macports.org/ticket/70319#comment:26 )
I had a feeling that the MacPorts I maintain had been a bit too quiet recently. Glad I dug a little deeper and realized I was overlooking that Call For Testing!
Hopefully, the 10.0 release will go smoothly and downstreaming it into MacPorts will be as relatively uneventful as it has been for me locally with the most recent snapshot.
#OpenSSH #CallForTesting #snapshots #OpenSource #SecureShell #Cryptography #Security #MacPorts
Almost a week behind the Call For Testing for OpenSSH 10.0!
(OpenSSH UNIX dev mailing list archive message on such things here:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2025-April/041855.html)
Preliminary results on macOS 15.4 leveraging MacPorts are lookin good so far:
./ssh -V
OpenSSH_9.9p2-snap20250407, LibreSSL 4.0.0
Running %make tests
"all tests passed"
So that's great too!
Note: this version removes DSA support.
Previously, that had been omitted from default compilation options (though there were some squeaky wheel MacPorts folks who ended up contributing the legacy_dsa variant to toggle that compilation option back on; I'm trying to figure out the best way to give them a heads up that they're going to need to maintain a patchset diff from upstream if they want to keep that variant. For the time being, hopefully updating the Trac issue will at least notified interested individuals:
https://trac.macports.org/ticket/70319#comment:26 )
I had a feeling that the MacPorts I maintain had been a bit too quiet recently. Glad I dug a little deeper and realized I was overlooking that Call For Testing!
Hopefully, the 10.0 release will go smoothly and downstreaming it into MacPorts will be as relatively uneventful as it has been for me locally with the most recent snapshot.
#OpenSSH #CallForTesting #snapshots #OpenSource #SecureShell #Cryptography #Security #MacPorts
Alexia ΘΔalright my dear wafrn users (bsky view full post with the link below)
I have just published TWO PRs that revamp the editor with a tweaked and more compact design, whilst also making it more consistent and nicer to use in mobile web browsers
and we are
LOOKING FOR FEEDBACK!
So if you wanna test, please head to this GitHub comment on desktop and this GitHub comment on mobile and click the Preview link!
Please, if you have GitHub, leave feedback there! Otherwise, just comment here INCLUDING whether you tested on Desktop or Mobile!
THIS ALSO INCLUDES BUGS, PLEASE TELL US OF BUGS AND JANK
As per a native app…we may get a beta soon, BUT NO PROMISES!
#wafrnDev #call-for-testing
Graham PerrinFreeBSD Project-provided repositories for kernel modules in the ports collection: usage
<https://blendit.bsd.cafe/post/821622>
14.1-RELEASE to 14.2-RELEASE
… an interim approach to avoiding the DRM graphics issue that was noted for 14.2-RELEASE before the release announcement …
#FreeBSD #upgrade #FAQ #Ludwig #LDWG #CFT #callfortesting #DRM #graphics #kmods #kernel
FreeBSD Project-provided repositories for kernel modules in the ports collection: usage - BlendIT - BSD Cafe
# 14.1-RELEASE to 14.2-RELEASE Essential reading: - installation information at https://www.freebsd.org/releases/14.2R/ [https://www.freebsd.org/releases/14.2R/] – you can create a configuration file for a Project-provided FreeBSD-kmods repo before beginning to follow the steps at https://www.freebsd.org/releases/14.2R/installation/#upgrade-binary [https://www.freebsd.org/releases/14.2R/installation/#upgrade-binary]. 1. mkdir -p /usr/local/etc/pkg/repos ; cd /usr/local/etc/pkg/repos 2. cp /etc/pkg/FreeBSD.conf ./FreeBSD-kmods.conf 3. ee ./FreeBSD-kmods.conf 4. change the repository name from FreeBSD to FreeBSD-kmods 5. change quarterly to kmods_quarterly_2 6. escape, save 7. cd 8. follow official installation information up to, and including, the second run of freebsd-update install 9. pkg upgrade --repository FreeBSD-kmods 10. ignore the mismatch (y) 11. if any upgraded kernel module is offered, proceed (y) 12. continue with official installation information – the first restart of the operating system, and so on 13. finally, re-edit /usr/local/etc/pkg/repos/FreeBSD-kmods.conf – change kmods_quarterly_2 to kmods_quarterly_${VERSION_MINOR} Notes: - the Project’s official call for testing (CFT) will lead to simplicity – please see https://old.reddit.com/r/freebsd/comments/1hd2h51/freebsd_projectprovided_repositories_for_kernel/m1ukuno/ [https://old.reddit.com/r/freebsd/comments/1hd2h51/freebsd_projectprovided_repositories_for_kernel/m1ukuno/] - the less simple steps, above, are an interim approach to avoiding the DRM graphics issue that was noted for 14.2-RELEASE before the release announcement – https://www.freebsd.org/releases/14.2R/errata/#open-issues [https://www.freebsd.org/releases/14.2R/errata/#open-issues] - the steps assume use of the traditional quarterly repo for packages of ports. https://wiki.freebsd.org/Ports/QuarterlyBranch [https://wiki.freebsd.org/Ports/QuarterlyBranch] should help to understand the difference between quarterly and latest - and beware of confusion with base_latest, which relates to pkgbase [https://wiki.freebsd.org/PkgBase] (base, separate from ports).
LiberaForms🚀 Great news!
LiberaForms now is beta testing End-to-End Encryption (E2EE) for form submissions! Your data stays private and secure, even from sysadmins.
Check out our blog for details on this first implementation and how it enhances privacy: https://blog.liberaforms.org/2024/08/05/e2ee-on-liberaforms-first-implementation/
Please let us know how this looks to you, your feedback is much appreciated.
#LiberaForms #E2EE #Privacy #OpenSource #Encryption #CyberSecurity #NLNet #CallForTesting
Evilham 
So, a bit of an unofficial #CallForTesting! 
#E2EE on @liberaforms is mostly ready in its first version, see details here:
https://farga.exo.cat/LiberaForms/server/issues/10#issuecomment-26199
It is ofc not ready for production and shouldn't be used on live instances where you care about your data; that's what the next two milestones are for :-).
If someone does try it, do write thoughts, impressions and comments :-)
E2EE: validate Initial Integration
Test different features and document anything that we detect as being incompatible with E2EE at this stage. As known examples, on the first iteration: - Users editing their own answers will be unsupported - Sharing an E2EE form will be unsupported - Some new features related to maps...