CVS log for pkgsrc/lang/mozjs78/Makefile

Up to [cvs.NetBSD.org] / pkgsrc / lang / mozjs78

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

*: bump for llvm 19 (shlib major changed)

*: recursive bump for icu 77 and libxml2 2.14

mozjs78: SunOS needs explicit libs.

*: recursive bump for icu 76 shlib major version bump

*: revbump for icu downgrade

*: recursive bump for icu 76.1 shlib bump

mozjs78: Unbreak. Port to Python 3.10.

mozjs78: mark as BROKEN

Needs porting to Python 3.10+

mozjs78: Switch SunOS over to illumos triple.

Required to ensure consistency with the rust target.

revbump after icu and protobuf updates

mozjs78: Add direct include of iconv.

Previously it was coming in via the clang build dependency, and thus falling
foul of indirect library checks.

*: recursive bump for icu 74.1

*: update for Python base package change

Instead of depending on one of the removed packages (that are now included
in the base Python packages), include batteries-included.mk to require
a Python version that supplies them.

Remove now included packages.

Bump PKGREVISION.

*: recursive bump for Python 3.11 as new default

revbump after textproc/icu update

massive revision bump after textproc/icu update

py37-reduce: Drop 37 from PYTHON_VERSIONS_ACCEPTED

Drop 37 from PYTHON_VERSIONS_ACCEPTED for all but
py-backports.cached-property (which exists only for 37, and I'm
guessing it will build fine and not cause trouble).

This follows the new plan of "37 is all but removed, with the
lang/python37 package remaining, but py37-foo are not built by
default" compromise to avoid problems from the current state of
massive py37-foo build failures while stopping short of outright
removal.

mozilla packages based on firefox78 are incompatible with python 3.10
due to a change to the collections library. Right now commit a workaround
until a proper fix appears.

*: recursive bump for perl 5.36

revbump for textproc/icu update

revbump for icu and libffi

mozjs78: update to 78.15.0

No distinct change log found. This is the final release of this branch.

mozjs78: update to 78.13.0

The full gamut of security fixes for this release is unknown, but, at
minimum, CVE-2020-16042 is addressed. (A full change log seems elusive:
the package's README points to a broken link, Mozilla advisories about
"memory safety hazards" can point to bug reports that can't be viewed,
etc.) This is the most current version that Debian has integrated,
which is where our package points to.

Successful build tests on:
NetBSD amd64/9.2_STABLE (with both Rust 1.52.1 and 1.54)
NetBSD i386/9.2_STABLE
OmniOS r151036

Fedora Linux 34 was not testable, as our packaging of LLVM 12.0.1 fails
to build on it. The upstream configuration continues to cap macOS build
support at 10.15.4. I updated our existing patch to allow 10.15.7, but
have no ability to test that OS, and no idea if 11.x would work.

This is effectively a minor leaf package now, and may best be removed
in future. I've updated this just in case issues emerge with the polkit
switch to duktape, which will first appear in our 2021Q3 branch. (That
is, I'm not aware of any issues, and definitely prefer duktape from a
packaging perspective.)

mozjs78: fix NetBSD i386 builds with Rust >= 1.50

The NetBSD i386 Rust 1.50 builds introduced two different targets (i586
and i686), where previously there was only one (i686). Unfortunately,
the upstream mozjs78 configuration script that narrows to the
appropriate compiler target is confused by this, since it was receiving
"i486" from pkgsrc tooling and didn't know how to pick from more than
one potential approximate match. I'm addressing it this (kludgy) way
for now, as I don't have time to go through Mozilla's scripting and
make adjustments, and I would like this building in the 2021Q2 branch.
If someone else feels there's a better way, please have at it. With
this tweak in place, I'm able to build the xfce4 meta package for
NetBSD/i386 9.2.

*: recursive bump for perl 5.34

mozjs78: update $HOMEPAGE

Fix PR pkg/56137 : lang/mozjs78: error: failed to resolve patches
c.f., https://phabricator.services.mozilla.com/D100485

revbump for textproc/icu

Normalize handling packages that require 64-bit atomic ops.

mozjs78: further SunOS build fixes

This results in a successful build and a js78 executable that runs in
my test environment (the most recent OmniOS release). However, test
suite execution yields an immediate failure with the message "too much
recursion", so it seems more work is still required here.

mozjs78: list an actual project homepage

mozjs78: add test target support

mozjs78: note powerpc atomic support is incomplete

mozjs78: Include bsd.prefs.mk before using it

mozjs78: Fix configure where the readline library isn't builtin.

This commit also moves the location of WRKSRC so that no patches are
applied to files in parent directories of WRKSRC.

mozjs78: include bsd.prefs.mk so $MACHINE_PLATFORM is defined

mozjs78: Remove PYTHON3 hack, it's no longer needed

mozjs78: Remove EOL whitespace

mozjs78: Adapt he@'s mozjs60 powerpc patches

mozjs78: fix builds on some 32-bit architectures

As with earlier versions, this expects 64-bit atomic operations.
Separately, there's an issue with an assertion in test code that makes
an assumption about the size of an index variable vs. size_t that
doesn't hold.

Test suite comparisons between resultant amd64 and i386 builds on
recent NetBSD releases reveal a similar number of failures (18 vs. 20),
mostly to do with date parsing, though i386 also fails with two IEEE
754 double precision tests.

I did look at carrying mozjs60 patches for NetBSD/powerpc forward, but
I don't have a viable test environment at the moment, and code
inspection suggests that may not be straightforward.

mozjs78: requires minimum GCC 7.1

mozjs78: record correct minimum Rust version

mozjs78: Fix Python dependencies. Add py-expat.

lang: Add mozjs78. Needed by newer gjs (needed by gnome-shell).

Based on work by Dan Cîrnaț and myself in wip.

This directory contains SpiderMonkey 78, the JavaScript engine by
Mozilla.