Late to the party, but I am not sure this is the right way(tm).

Done, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245505

I have tried this and indeed it now allows me to enable the webcam. However, it the picture is flashed over with a green background few times a second and it produces the following (possibly unrelated) error message one the console:

In D24330#535212, @cem wrote:

We may be missing a DEPEND line on libv4l. Poudriere testport should shake that out, when someone gets a chance.

Thanks, yes, reverting it locally fixed that for me. Shouldn't makefs become part of the bootstrap tools then? Requiring 12.1 is a bit tight...

I tried to build SVN head (r353191) today on 12.0-RELEASE-p10 amd64 and I am getting an error when trying to build CDs:

Thank you @cy for taking care of this!

In D19343#428260, @pkubaj wrote:

Yes, this builds ok on powerpc64 when compiling with GCC8. So you should set USES=compiler:c11.

All issues fixed

Use tag name as suggested by cy@

Merged changes to the ports tree in the meantime

Make portlint happy

This is a patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208098 to fix the problems. Feedback welcome.

Great, thanks!

mdoc(7) nitpicking :(

In D15535#328087, @brooks wrote:

In D15535#328078, @saper_saper.info wrote:

I have one question. From what I see in the code for brk() and sbrk() got removed from the C library, but the system call sys_obreak still exists, correct?

Hmm, that's a bug. We should remove it (or at least make it ENOSYS).

Are there any architecture-specific reasons for removal? (Something that riscv and aarch64 cannot do but amd64 and i386 can)?

I have one question. From what I see in the code for brk() and sbrk() got removed from the C library, but the system call sys_obreak still exists, correct?

In D6464#327808, @emaste wrote:

A bit late to the party, but I got bitten by this today

Can you explain how?

A bit late to the party, but I got bitten by this today - where this should be documented? sbrk(2) manpage?

In D11863#246963, @luca.pizzamiglio_gmail.com wrote:

We're also working to make FreeBSD more nodejs friendly. Our goal is to bring electron.io and Atom to FreeBSD.

Mixing packages from the portstree and npm is, in general, not a good idea, because different projects could require different version of the same package. Our approach is to bring in the portstree only the built/native components and somehow tell npm to use those, instead of rebuild, to minimize potential conflicts.

Is asset generation working during the build stage? If yes, I think we can get rid of most node_modules - most importantly we can discard node-sass.

node-gyp is brought by npm, at least in some version (often a newer version of node-gyp is required by the modules).

How does node-gyp fit into this picture? This is the component that should pull in gmake dependency.

In D10618#227002, @jrm wrote:

Are you building the port? The optional gem, bootsnap, was removed in the port's Gemfile patch.

Today with a fresh mastodon master I got the following (not from the port)

Adding -DBOOT_BIOSDISK_DEBUG does not seem to influence gptzfsboot very much (I am even getting the same binary back).

It seems to me that this change cause