multimedia/libvpx: update to 1.4.0

[jbeich]

Summary

ABI isn't compatible, so bump PORTREVISION in consumers.

IMPORTANT: It requires more care than the actual update.

No ACC report for this version. Current one for Git is 341 commits ahead -> unreliable.

Changes: https://chromium.googlesource.com/webm/libvpx/+/v1.4.0

Test Plan

libvpx build on 8.4R amd64, 9.3R i386, 10.1R amd64, 10.1R i386, 11.0C i386.
libvpx build on 8.4R amd64 and 10.1R i386 with inversed options.
libvpx build on 11.0C amd64 (tainted) with gcc5/libc++.
libvpx build on 11.0C amd64 (tainted) with zsh -> bash symlink under PATH.
www/firefox, multimedia/ffmpeg26 (via mpv) runtime against libvpx 1.4.0 with VP9 video.

Not much else i.e., the following risks are ignored for being [hard to test]:

• [exp-run] API breakage (removed symbols/macros) D2570#48105
• [exp-run] overlinking or ports with underspecified dependencies D2570#48105 except for leafs
• [diverse environments] runtime regressions on some architectures, toolchains, optimizations
• [luck] dlopen quirks such as using bundled headers for system library

[jbeich]

Approval request sent to @ashish (maintainer) via mail.

graphics/php5-gd/Makefile

4

Oops, I forgot to re-bump after restoring PORTREVISION in lang/php5*. Fixed locally.

[bapt]

This comment was removed by bapt.

[jbeich]

There was no exp-run as I'm not sure it's even required. The number of consumers isn't that big compared to, say, graphics/png. portmgr is supposed to know better when to weigh risks against the cost of exp-run.

Also, exp-run may not catch all cases of ABI breakage e.g., in leaf ports.

[jbeich]

• Fixed typos in php*-gd and handbrake
• Rebased PORTREVISION against changes in net/mediastreamer
• Added missing newline before $FreeBSD$ in multimedia/libvpx/files/patch-build_make_configure.sh for consistency with @ashish style
• Enabled svn:keywords in multimedia/libvpx/files/patch-build_make_configure.sh

@bapt wrote:

Have you build test all consumers?

No, lack of resources and it'd be close to local exp-run.

[antoine]

Exp-run results on 10.1 amd64:

http://package18.nyi.freebsd.org/build.html?mastername=101amd64-default-D2570&build=2015-05-18_19h56m07s

There are 4 failures that seem related to the update

[jbeich]

In D2570#47819, @antoine wrote:

There are 4 failures that seem related to the update

graphics/*gd VPX=on failure went unnoticed. Anyway, those're a fallout from
https://chromium.googlesource.com/webm/libvpx/+/9cdaa3d%5E!/

Can you re-try with updated diff + OPTIONS_SET=VPX in make.conf ?

[antoine]

Unrelated to the libvpx update, but some ports do not respect DISABLE_MAKE_JOBS / MAKE_JOBS_NUMBER :

root 35699 0.0 0.0 14648 3700 2 I+J 15:00 0:00.05 gmake -j32 -C /wrkdirs/usr/ports/www/libxul/work/mozilla-esr31/obj-x86_64-portbld-freebsd10.1
root 48628 0.0 0.0 14648 3868 2 I+J 15:00 0:00.06 gmake -j32 -C /wrkdirs/usr/ports/www/firefox-esr/work/mozilla-esr31/obj-x86_64-portbld-freebsd10.1
root 63764 0.0 0.0 14648 3752 2 S+J 15:00 0:00.06 gmake -j32 -C /wrkdirs/usr/ports/www/firefox/work/mozilla-release/obj-x86_64-portbld-freebsd10.1
root 74904 0.0 0.0 14648 2656 2 I+J 15:01 0:00.01 gmake -j32 -C /wrkdirs/usr/ports/mail/thunderbird/work/comm-esr31/obj-x86_64-unknown-freebsd10.1
root 83814 0.0 0.0 14648 3728 2 I+J 15:01 0:00.07 gmake -j32 -C /wrkdirs/usr/ports/www/seamonkey/work/comm-release/obj-x86_64-portbld-freebsd10.1

[antoine]

Exp-run results on 10.1 amd64:

http://package18.nyi.freebsd.org/build.html?mastername=101amd64-default-D2570&build=2015-05-19_14h53m13s

[jbeich]

Thanks. Green now. Back to waiting for approval(s) now.

In D2570#47944, @antoine wrote:

Unrelated to the libvpx update, but some ports do not respect
DISABLE_MAKE_JOBS / MAKE_JOBS_NUMBER :

gecko bugs are indeed unrelated. I remember this one being tricky and it may not have been completely fixed due to configure/client.mk/mach chaining involved.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184630

root 63764 0.0 0.0 14648 3752 2 S+J 15:00 0:00.06 gmake -j32 -C
/wrkdirs/usr/ports/www/firefox/work/mozilla-release/obj-x86_64-portbld-freebsd10.1

MAKE_JOBS_NUMBER=1 should work. Undefined -jN build leads to undefined behavior. I'm not sure about adding a workaround for bsd.port.mk bug like USES=waf and USES=ninja did. Also,...

# Automatically add -jN to make flags if not defined. N defaults to number of cores.
ifeq (,$(findstring -j,$(MOZ_MAKE_FLAGS)))
  cores=$(shell $(PYTHON) -c 'import multiprocessing; print(multiprocessing.cpu_count())')
  MOZ_MAKE_FLAGS += -j$(cores)
endif

cpu_count() should probably return the number of available cores after subtracting user overrides via cpuset(1). As the python function prefers sysconf(3) one could divorce _SC_NPROCESSORS_ONLN from _SC_NPROCESSORS_CONF like Linux did.

[jbeich]

@ashish granted approval. Do I need to wait for portmgr, use the blanket or ask maintainers of the patched ports separately?

• @dinoex for graphics/gd, non-upstreamed fix
• @ale for graphics/php5-gd, graphics/php55-gd, graphics/php56-gd, non-upstreamed libgd fix
• multimedia for multimedia/gstreamer-plugins-vp8, upstreamed gst-plugins-good fix

[kwm]

Approved with my multimedia@ hat on (for Gstreamer)

[jbeich]

Rebase after rP387082 to make sure keywords/props in patches are gone:

multimedia/libvpx/files/patch-nestegg_halloc_src:2:$FreeBSD$
multimedia/libvpx/files/patch-nestegg_halloc_src:19:$FreeBSD$
multimedia/libvpx/files/patch-build_make_configure.sh:11:$FreeBSD$

[jbeich]

Closed by commit rP388940 (authored by @jbeich). @dinoex did reply on 2015/05/26 and then silence till timeout.