Thanks!

I committed R11:3b2ff2ef194c and R11:f0f843322841 (plus a quick typo fix R11:5f6b3eda2234) to address this issue. You can now set:

DEFAULT_VERSIONS+= ebur128=legacy

in make.conf to use the C implementation tree-wide.

In D41048#943752, @eduardo wrote:

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

pkg-updating(8) - display UPDATING entries of software packages

In D41048#934479, @adamw wrote:

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

You still want to put stuff in UPDATING, but pkg-message is actually the most helpful as it's visible to everyone using pkg (FreeBSD upstream, poudriere, etc.).

See https://docs.freebsd.org/en/books/porters-handbook/pkg-files/#porting-message, especially "Example 4: Display a Message on Upgrade."

Added pkg-message.

After discussion in IRC I updated the patch:

• Keep old names for user and group is "technical debt" and "confuse the users" (especially new).
• Use new UID and GID is difficult to migrate for running systems - find and change owner for all files required for port.

So, IMHO, rename user and group is "the lesser of the evils".

In D41473#944573, @arrowd wrote:

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.

All correct:

• EBUR used for PLUS only, so if turn on EBUR, then automatic turn on PLUS;
• PLUS require EBUR.

This is the "logic".

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

pkg-updating(8) - display UPDATING entries of software packages

Great job!

Fixed text-to-speech options.

@vvd You can remove PIPEWIRE_DESC lines in ports that are essentially the same as a generic one, and keep the ones that are different/more specific.
Ports can define their own descriptions for options when they are more informative than the generic one.

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

I agree with arrowd@

This should probably stay, as it is more accurate. It clearly explains what's pipewire is used for.

I assumed this, but wanted to hear the views of the maintainers.

https://cgit.freebsd.org/ports/commit/?id=3bc8803e5c4a96b60ffe5fa6887e2b73e0df7756

Done.

Combine conditions.

Documented the new shorthand syntax in D34614. Depends on this revision.

Yes.

Don't push it. I also forgot to add suport for [+|-].

Can you add a section here about the new shorthand syntax while at it?

Accept floating point numbers as input.

D34612 depends on this revision.

Ran igor(1) on both mixer.8 and mixer.3. The line changes were made because mandoc -Tlint was printing warnings, so I wanted them to go away. :-)

Could you also run igor mixer.3? You can find igor in the package repo.

Fixed.

Your changes to mixer.8 seem to revert recent patches. Please submit a rebased patch.

Alright then, we can abandon it!

Current plan is to release 13.1 April 26, 2022 .

Mostly for completeness, but we can abandon it if 13.1 is close to release.

Technically no, but I worried about some unknown side effects.

Since these are just the kernel patches, would it break anything if we push them in 13.0-RELEASE as well?

I think all of this will be part of the coming 13.1! So let's just abandon this one?

Bump.

In D34591#783694, @hselasky wrote:

Looks good. Are there more patches coming?

Looks good. Are there more patches coming?

I would appreciate if you could build test a bit more, like "make buildworld", before submitting patches.

In D33142#749020, @hselasky wrote:

Comments sometimes help verify that the code has been implemented correctly.

Comments sometimes help verify that the code has been implemented correctly.

Can you explain a bit more the motivation here?

I think each function should have a description:

@gbe you should probably commit this yourself since I don't have commit rights. :-)