diff --git a/pypy3.spec b/pypy3.spec
index 218ec39..50ecfc0 100644
--- a/pypy3.spec
+++ b/pypy3.spec
@@ -1,7 +1,7 @@
 Name:           pypy3
 Version:        5.10.0
 %global pyversion 3.5
-Release:        2%{?dist}
+Release:        3%{?dist}
 Summary:        Python 3 implementation with a Just-In-Time compiler
 
 # LGPL and another free license we'd need to ask spot about are present in some
@@ -224,10 +224,7 @@ BuildRequires:  /usr/bin/free
 BuildRequires:  perl-interpreter
 %endif
 
-# No prelink on these arches
-%ifnarch aarch64 ppc64le
 BuildRequires:  /usr/bin/execstack
-%endif
 
 # For byte-compiling the JIT-viewing mode:
 %if %{with_emacs}
@@ -458,39 +455,6 @@ BuildPyPy \
 
 
 %install
-# Install the various executables:
-
-InstallPyPy() {
-    ExeName=$1
-
-    # To ensure compatibility with virtualenv, pypy finds its libraries
-    # relative to itself; this happens within
-    #    pypy/translator/goal/app_main.py:get_library_path
-    # which calls sys.pypy_initial_path(dirname) on the dir containing
-    # the executable, with symlinks resolved.
-    #
-    # Hence we make /usr/bin/pypy be a symlink to the real binary, which we
-    # place within /usr/lib[64]/pypy-1.* as pypy
-    #
-    # This ought to enable our pypy build to work with virtualenv
-    # (rhbz#742641)
-    install -m 755 %{goal_dir}/$ExeName %{buildroot}/%{pypyprefix}/$ExeName
-    ln -s %{pypyprefix}/$ExeName %{buildroot}/%{_bindir}
-
-    # The generated machine code doesn't need an executable stack,  but
-    # one of the assembler files (gcmaptable.s) doesn't have the necessary
-    # metadata to inform gcc of that, and thus gcc pessimistically assumes
-    # that the built binary does need an executable stack.
-    #
-    # Reported upstream as: https://codespeak.net/issue/pypy-dev/issue610
-    #
-    # I tried various approaches involving fixing the build, but the simplest
-    # approach is to postprocess the ELF file:
-%ifnarch aarch64 ppc64le
-    execstack --clear-execstack %{buildroot}/%{pypyprefix}/$ExeName
-%endif
-}
-
 mkdir -p %{buildroot}/%{_bindir}
 mkdir -p %{buildroot}/%{pypyprefix}
 
@@ -517,6 +481,17 @@ find \
 
 mkdir -p %{buildroot}/%{pypyprefix}/site-packages
 
+# The generated machine code doesn't need an executable stack,  but
+# one of the assembler files (gcmaptable.s) doesn't have the necessary
+# metadata to inform gcc of that, and thus gcc pessimistically assumes
+# that the built binary does need an executable stack.
+#
+# Reported upstream as: https://codespeak.net/issue/pypy-dev/issue610
+#
+# I tried various approaches involving fixing the build, but the simplest
+# approach is to postprocess the ELF file:
+execstack --clear-execstack %{buildroot}/%{pypyprefix}/bin/pypy3
+
 ln -s ./pypy3 %{buildroot}%{pypyprefix}/bin/pypy%{pyversion}
 ln -s %{pypyprefix}/bin/pypy%{pyversion} %{buildroot}%{_bindir}/pypy%{pyversion}
 ln -s pypy%{pyversion} %{buildroot}%{_bindir}/pypy3
@@ -666,6 +641,12 @@ rm -f %{buildroot}%{_libdir}/pypy3-5.2.0.tar.bz2 \
 # wtf? This is probably masking some bigger problem, but let's do this for now
 mv -v lib-python/3/test/regrtest.py-new lib-python/3/test/regrtest.py || :
 
+# since 5.10.0, the debug binaries are built and shipped, making the
+# pypy3 package ~350 MiB. let's remove them here for now and TODO figure out why
+rm -f %{buildroot}%{pypyprefix}/bin/pypy3.debug
+rm -f %{buildroot}%{pypyprefix}/bin/libpypy3-c.so.debug
+
+
 %check
 topdir=$(pwd)
 
@@ -835,6 +816,12 @@ CheckPyPy %{name}-stackless
 
 
 %changelog
+* Fri Dec 29 2017 Miro Hrončok <mhroncok@redhat.com> - 5.10.0-3
+- Remove never used InstallPyPy function
+- Actually call execstack as originally intended
+- Use execstack on all arches (it's available now)
+- Don't ship the debug binaries
+
 * Thu Dec 28 2017 Miro Hrončok <mhroncok@redhat.com> - 5.10.0-2
 - Fixed upstream issues #2717 and #2718 (re-enable test_socket)
 - Use pypy2 when building (it's faster and works this time)