- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
use TEST block, add cairo
Applied feedback. I'll change the commit msg shortly to reflect that it's a skip now.
Abandoning as superseded by https://reviews.freebsd.org/D57297.
differentiate iscsi / nvmeof
Can you please confirm the author field for the commit:
What implements /dev/full these days?
$ uname -a FreeBSD universe16a.freebsd.org 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n285776-10e342c1ec78: Sat May 9 09:21:00 UTC 2026 root@build-16.freebsd.org:/usr/obj/usr/src/sys/CLUSTER16 amd64 $ ls /dev/full ls: /dev/full: No such file or directory
Initialize m_phdrs in both places.
@ziaee fwiw for configuring prime I would recommend using the "autoconfig" style configuration files which I covered here: https://badland.io/prime-configuration.md instead of using nvidia-xconfig or writing a full configuration yourself. And yes you probably want to set intel as the PrimaryGPU.
Patch with suggested changes:
So, on multiple-package machines, this driver will malfunction as described in one of the inline comments (and I wasn't able to find a quick way to disable it in this case). I guess that's tolerable as a first shot.
In D57293#1312969, @adrian wrote:nice catch! Why's this not panicing though? I thought I saw a lock assertion in usb_command_wrapper() ?
nice catch! Why's this not panicing though? I thought I saw a lock assertion in usb_command_wrapper() ?
It seems that desktop-file-validate and appstreamcli utils are only invoked as a part of make test.
Consider adding OPTIONS_DEFINE= TEST and moving these deps to TEST_BUILD_DEPENDS.
Pass phdrs to the note checker.
Check that AT_PHDRS calculation does not wrap.
In D57274#1312947, @emaste wrote:I mean, sure, I guess, but what's the threat model here? I sure hope you trust the tarballs you're unpacking to install a system not to be malicious, otherwise what's the point?
I could come up with a contrived exploit scenario, but yes if someone controls the tarballs being unpacked during install it's likely much easier to just provide a trojaned binary.
This came to secteam and I thought "sure, why not."
In D57274#1312947, @emaste wrote:I mean, sure, I guess, but what's the threat model here? I sure hope you trust the tarballs you're unpacking to install a system not to be malicious, otherwise what's the point?
I could come up with a contrived exploit scenario, but yes if someone controls the tarballs being unpacked during install it's likely much easier to just provide a trojaned binary.
This came to secteam and I thought "sure, why not."
Apart from the following stage-qa warning this looks great
I mean, sure, I guess, but what's the threat model here? I sure hope you trust the tarballs you're unpacking to install a system not to be malicious, otherwise what's the point?
Refactor commit msg