trips on it and configure fails:
CMake Error: CMake can not determine linker language for target: history-list.orig
CMake Error: CMake can not determine linker language for target: transfers.orig
CMake Error: CMake can not determine linker language for target: apps.orig
CMake Error: CMake can not determine linker language for target: notes.orig
Changelog:
"Enpower -l (tag-listing mode). This is now able to emit all tags in JSON
formatted output via -j, which makes it easy for dynamic sites to play with
tag listings in any way they choose. (See sblg(1) for an explanation of the
output format.) Also add -r, which stipulates that -l will print tag-first.
This is most useful for -j, as it allows for easy browsing by tag name."
- pass the option NO_GETTEXT=1 to git to disable gettext support.
- add a patch patches/patch-setup_c to not open /dev/null in the chroot.
- add a OpenBSD httpd (with slowcgi) example to the README.
- add an explanation a static gzip binary is required for .tar.gz snapshot support.
(and fix RCS Ids while here)
Fixes MFSA 2017-08/CVE-2017-5428, see
https://www.mozilla.org/en-US/security/advisories/mfsa2017-08/
While here, add a patch from semarie@ (tested by and ok danj@) to tweak
a last-minute change in the jit engine memory allocator that happened to
fix a security issue in 52 branch (bug #1334933/CVE-2017-5400) - see
https://hg.mozilla.org/releases/mozilla-esr52/rev/6b35bbf96b67.
Sadly, this change resulted in a browser crashing at startup
on OpenBSD with the default limits, because the jit engine tried to
allocate 1Gb (previously 640Mb in #1334933, then 1Gb because of
#1337561, see
https://hg.mozilla.org/releases/mozilla-esr52/rev/65bb26d07408) and hit
the default datasize ulimit of 768Mb. The patch makes it allocate 128Mb
instead (as it's done on 32bit architectures), while a better (?) fix
might be devised in bug #1347139.
Generally speaking, if you see firefox crashing with ENOMEM errors,
raise the datasize limit for your login class, write your own wrapper
script to temporarly raise the limit when starting firefox, or stop
using the modern web. Websites are ginormous, deal with it.
Fixes MFSA 2017-08/CVE-2017-5428, see
https://www.mozilla.org/en-US/security/advisories/mfsa2017-08/
While here, add a patch from semarie@ (tested by and ok danj@) to tweak
a last-minute change in the jit engine memory allocator that happened to
fix a security issue in 52 branch (bug #1334933/CVE-2017-5400) - see
https://hg.mozilla.org/releases/mozilla-esr52/rev/6b35bbf96b67.
Sadly, this change resulted in a browser crashing at startup
on OpenBSD with the default limits, because the jit engine tried to
allocate 1Gb (previously 640Mb in #1334933, then 1Gb because of
#1337561, see
https://hg.mozilla.org/releases/mozilla-esr52/rev/65bb26d07408) and hit
the default datasize ulimit of 768Mb. The patch makes it allocate 128Mb
instead (as it's done on 32bit architectures), while a better (?) fix
might be devised in bug #1347139.
Generally speaking, if you see firefox crashing with ENOMEM errors,
raise the datasize limit for your login class, write your own wrapper
script to temporarly raise the limit when starting firefox, or stop
using the modern web. Websites are ginormous, deal with it.
The last release of elinks was in 2009, and it has since come to our attention
that it does not verify the authenticity of SSL certificates:
https://marc.info/?l=elinks-dev&m=148896031830582&w=2
We've not heard from upstream, so for now we are removing elinks from ports.
For a more modern text-based browser with SSL certificate verification, see
www/lynx.
OK jca@
