Address man page review comments. Word wrap at 80 columns.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 31 2018
Address man page style review for new lines and correct case of BIOS use.
Add a man page update like a good dev.
Oct 30 2018
This is probably completely wrong on multiple levels, but this certainly does allow me to use my headphones again on my Skylake Intel HDA box.
Oct 29 2018
Oct 25 2018
Oct 22 2018
This definitely fixes the build and runtime of clementine-player (qt4).
Oct 19 2018
In D17618#376145, @yuripv wrote:Sean, could you please give this a try on ref12-ppc64?
This is running live on the host archon.nyi.freebsd.org that hosts ref12-ppc64.freebsd.org. We can do buildworlds and network things now. This is awesome.
In D17603#376077, @sbruno wrote:In D17603#376024, @yuripv wrote:issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).
Now the amd64 cross-built locale data matches the one built natively on powerpc64.
Updating ref12-ppc64 for verification.
In D17603#376024, @yuripv wrote:issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).
Now the amd64 cross-built locale data matches the one built natively on powerpc64.
Oct 18 2018
In D17603#375981, @yuripv wrote:In D17603#375980, @sbruno wrote:In D17603#375978, @yuripv wrote:In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?
I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.
Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?
Thank you!
In D17603#375978, @yuripv wrote:In D17603#375975, @sbruno wrote:I'll apply this to the fbsd cluster build.
The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?
I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.
I'll apply this to the fbsd cluster build.
I'll test this against clementine-player today and see if it can do SSL/TLS connections for streaming. That should give us a bit of a warm fuzzy.
This allows audio/murmur to build again.
Oct 15 2018
@erj do you want to ask RE permission to commit this?
Oct 14 2018
Oct 12 2018
Apply openssl 1.1.1 update patch only if running on a FreeBSD version where
openssl 1.1.1 exists.
In D17524#374179, @antoine wrote:The USE_* section should be below the LICENSE section
In D17528#374172, @antoine wrote:There is no ${WRKSRC}/LICENSES , was this tested?
FATAL: Makefile: license specified is BSD3CLAUSE OTHERBSDLIKELICENSES, but LICENSE_FILE specified is for BSD3CLAUSE.
Tested on FreeBSD 12 natively and compiled in poudriere.
Oct 11 2018
Test builds of 12/11/10 on i386/amd64 build and pkg fine.
@yuripv Do you want me to commit this or are you going to be able to send the request to release engineering?
Oct 5 2018
In D17442#372066, @erj wrote:It's a reasonable change, but it's still kind of a surprise to me that em doesn't support IPv6 hardware offloads.
Does this require a LICENSE or some sort?
Oct 1 2018
Ok, whom would like to submit this to re@ to get it into the tree?
Sep 22 2018
Sep 21 2018
Sep 19 2018
Sep 18 2018
Sep 14 2018
Sep 6 2018
Aug 27 2018
Can you bump PORTVERSION when you commit this?
Aug 26 2018
Aug 25 2018
Aug 12 2018
In D11958#354675, @sevan wrote:A new release of mandoc was posted last week, is this still valid?
Aug 8 2018
Jul 31 2018
Jul 25 2018
Jul 24 2018
Jul 14 2018
Reopen at the request of submitter.
This works for us in the FreeBSD cluster. Thanks!
Jul 13 2018
Let me do a quick test on the cluster ThunderX1 machine.
Jul 11 2018
Jul 10 2018
From the release notes and will be in the commit log:
0.o Remove the other directories from this review.
Jul 8 2018
In D16164#342962, @cem wrote:In D16164#342951, @erj wrote:can iflib.ko be created and then the driver modules depend on that?
That would be really nice. :-P
Driver modules already can and do depend on iflib, without forcing it to be a kld object (.ko) — grep for MODULE_DEPEND(..., iflib, ...).
If the idea is pulling iflib out of the kernel just for space savings, I'm not sure that really makes sense on any platform that supports iflib drivers anyway (i.e., non-embedded).
Please do add the IFLIB option to most/all GENERICs simultaneously with this change, though.
Jul 7 2018
In D16164#342938, @rgrimes wrote:Does this not also make it so that these drivers require IFLIB, so they need to be marked as such in GENERIC/NOTES/etc and man pages?