Fix style, re-using computer values from scb->oifp->if_hw_addr

I've run my build and run-time tests on i386 and amd64. Currently I'm unable to run a build test on aarch64.
BTW, it's look good for me.

Following the PHB rules about DISTVERSION on github projects without tag

Removing the unuseful patch file files/patch-src_common_linux_elfcoredump.h

Fixing the date/version, as suggested

Adopted the corrected versioning pocedure for github projects without tags

Even if I don't understand how it's possible, sys/elf_common.h fix
the definition of the missing macro. Adopting it.

• Silencing post-patch actions
• Fixing the build on i386

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

It looks good to me. My build and run tests are positive.

No, but I can do it.
Should I re-create the patch or just link this review to the URL field of the PR?
Build logs are also needed?

It looks good to me.

I'm totally fine with this patch.
Generally speaking, all ports depending to node should have an OPTION about the node version.
More generally speaking, I guess, I can spend some time to add USES= node and DEFAULT_VERSIONS+= node=6 to the framework, that's a more general approach.

Ok to commit!

Here you can find the build log of chromium and chromium-ng on all supported FreeBSD versions.

Relaxing dependencies even more, requiring c++11-libs and, probably, it works on more architecture.

I ran a build on a different machine, different jail, different poudriere, same error.
The full build log is here.

Pong,
My poudriere jails are only based on RELEASE, currently 10.3-RELEASE-p20. I've checked the /tmp directory on my poudriere jail and it's empty.
If it works on your jails based on RELEASE, it could be some system limit poudriere is reaching on my laptop. Tomorrow I'll have the opportunity to build it on a bigger server and I'll re-check. An EXP-run maybe can definitely solve it.

I've built chromium-ng and chromium on FreeBSD 11.0 and 10.3 on adm64.

Fixing backslashes.

We have a heavy build issue on FreeBSD 10.3, on i386 and amd64.
It looks like that clang crashes:

• Removing unuseful dependencies
• Fixing the install target after PORTNAME renaming

In D11074#237591, @jhb wrote:

For some reason 'arc patch xxxx' didn't work after your last change. Can you let me know which patch files you updated?

I've tested the new gdb 8 against my test suite and it works really good.
Once PORTREVISION and the python requirements are fixed, the diff is ready to be merged.

Re-closing this revision.

Fixing two patching issues with new patch files and a not up-to-date Makefile (Portervision is 2)

This revision is now obsolete.
D11465 is the current one.

In D10696#227510, @jrm wrote:

Actually, taking a closer look at $WRKSRC, I wonder if do-install should be changed.

WRKSRC is now simply

./bin
./bin/yarn
./bin/yarn.js
./bin/yarnpkg
./bin/yarnpkg.cmd
./bin/yarn.cmd
./package.json
./lib
./lib/v8-compile-cache.js
./lib/yarn-cli.js
./LICENSE

Why not just install what's in bin/ to ${PREFIX}/bin and what's in lib to ${PREFIX}/lib? Where should package.json go?

I spent a couple of week on holiday. Today I performed several tests and I'm very happy with all of your modifications. Thanks for the contribution!

The patch is good for me.

Small fix suggested in the Makefile

A note about architectures: devel/gdb is tested on i386, amd64, powerpc and powerpc64; at the moment, sparc64 is excluded (ONLY_FOR_ARCHS in the Makefile)