proj/gentoo: Initial commit

This commit represents a new era for Gentoo:
Storing the gentoo-x86 tree in Git, as converted from CVS.

This commit is the start of the NEW history.
Any historical data is intended to be grafted onto this point.

Creation process:
1. Take final CVS checkout snapshot
2. Remove ALL ChangeLog* files
3. Transform all Manifests to thin
4. Remove empty Manifests
5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$
5.1. Do not touch files with -kb/-ko keyword flags.

Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests
X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project
X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration
X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn
X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts
X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration
X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging
X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed

1 files changed, 53 insertions, 0 deletions

diff --git a/dev-lang/spidermonkey/files/spidermonkey-1.8.5-ia64-fix.patch b/dev-lang/spidermonkey/files/spidermonkey-1.8.5-ia64-fix.patch
new file mode 100644
index 000000000000..bebe5587180f
--- /dev/null
+++ b/dev-lang/spidermonkey/files/spidermonkey-1.8.5-ia64-fix.patch
@@ -0,0 +1,53 @@
+https://bugzilla.mozilla.org/show_bug.cgi?id=589735
+
+--- a/js/src/jsgcchunk.cpp	2011-03-31 21:08:36.000000000 +0200
++++ b/js/src/jsgcchunk.cpp	2012-11-02 10:36:08.324453878 +0100
+@@ -318,15 +318,48 @@
+ static void *
+ MapPages(void *addr, size_t size)
+ {
++#if defined(__ia64__)
++    /*
++     * The JS engine assumes that all allocated pointers have their high 17 bits clear,
++     * which ia64's mmap doesn't support directly. However, we can emulate it by passing
++     * mmap an "addr" parameter with those bits clear. The mmap will return that address,
++     * or the nearest available memory above that address, providing a near-guarantee
++     * that those bits are clear. If they are not, we return NULL below to indicate
++     * out-of-memory.
++     * 
++     * The addr is chosen as 0x0000070000000000, which still allows about 120TB of virtual 
++     * address space.
++     * 
++     * See Bug 589735 for more information.
++     */
++#endif
++
+     /*
+      * We don't use MAP_FIXED here, because it can cause the *replacement*
+      * of existing mappings, and we only want to create new mappings.
+      */
++#if defined(__ia64__)
++    void *p = mmap(addr ? addr : (void*)0x0000070000000000,
++                   size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
++                   -1, 0);
++#else
+     void *p = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+                    -1, 0);
++#endif
+     if (p == MAP_FAILED)
+         return NULL;
++#if defined(__ia64__)
++    /* 
++     * If the caller requested a specific memory location, verify that's what mmap returned.
++     * Otherwise: If the allocated memory doesn't have its upper 17 bits clear, consider it 
++     * as out of memory.
++     */
++    if (addr && p != addr
++        || !addr && ((long long)p & 0xffff800000000000)) {
++#else
++    /* If the caller requested a specific memory location, verify that's what mmap returned. */
+     if (addr && p != addr) {
++#endif
+         /* We succeeded in mapping memory, but not in the right place. */
+         JS_ALWAYS_TRUE(munmap(p, size) == 0);
+         return NULL;