Dear Maintainer,

today's stable update of Emacs GTK (1:28.2+1-15+deb12u3) failed with a
strange compilation error in elpa-folding.  After removing elpa-folding
(and the dependent emacs-goodies-el) the update was successful.  Trying
to reinstall emacs-goodies-el and elpa-folding still fails afterwards:

# apt install emacs-goodies-el
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  elpa-folding
The following NEW packages will be installed:
  elpa-folding emacs-goodies-el
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 112 kB of archives.
After this operation, 318 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.nl.debian.org/debian bookworm/main amd64 elpa-folding all 0.0~git20220110.1ce338b-1 [62.1 kB]
Get:2 http://ftp.nl.debian.org/debian bookworm/main amd64 emacs-goodies-el all 42.4 [49.5 kB]
Fetched 112 kB in 0s (667 kB/s)
Selecting previously unselected package elpa-folding.
(Reading database ... 686814 files and directories currently installed.)
Preparing to unpack .../elpa-folding_0.0~git20220110.1ce338b-1_all.deb ...
Unpacking elpa-folding (0.0~git20220110.1ce338b-1) ...
Selecting previously unselected package emacs-goodies-el.
Preparing to unpack .../emacs-goodies-el_42.4_all.deb ...
Unpacking emacs-goodies-el (42.4) ...
Setting up elpa-folding (0.0~git20220110.1ce338b-1) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-folding for emacs
install/folding-20220110.1718: Handling install of emacsen flavor emacs
install/folding-20220110.1718: byte-compiling for emacs

In toplevel form:
folding.el:1637:13: Warning: Package cl is deprecated
folding.el:1718:6: Error: Native elisp load failed: "/tmp/comp-lambda-z2mAEN.eln", "/tmp/comp-lambda-z2mAEN.eln: failed to map segment from shared object"
ERROR: install script from elpa-folding package failed
dpkg: error processing package elpa-folding (--configure):
 installed elpa-folding package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of emacs-goodies-el:
 emacs-goodies-el depends on elpa-folding; however:
  Package elpa-folding is not configured yet.

dpkg: error processing package emacs-goodies-el (--configure):
 dependency problems - leaving unconfigured
Processing triggers for install-info (6.8-6+b1) ...
Errors were encountered while processing:
 elpa-folding
 emacs-goodies-el
E: Sub-process /usr/bin/dpkg returned an error code (1)

What can be the reason for this compilation error?

Hi Thomas,

Thanks for the bug report, reply follows inline.

Thomas Dorner <debian-bugs@th-dorner.de> writes:

I agree this is strange, because native-compilation shouldn't execute as
part of dpkg configure.

Out of curiosity, did you get root with "sudo -s"?  Try this:

  su -  # or if you don't have the root account enabled: sudo -i
  apt clean  # mitigates the unlikely case the download was corrupted
  apt purge elpa-folding
  apt install elpa-folding

[snip]

/\ This is the strange part.  I don't understand why native-compilation
is being triggered.  That said, have you mounted /tmp with "-o noexec"?
I agree that that it's essential mount anything writeable with noexec;
however, this breaks native-compilation.

This bug wasn't triggered when apt upgraded on my system, I couldn't
trigger it with dpkg-reconfigure elpa-folding, and I wasn't able to
reproduce this in a clean bookworm schroot.

  apt install emacs-goodies-el
  # enable bookworm-security
  apt update && apt upgrade
  # Successful update

Looking forward to your findings!
Nicholas

Hi Nicholas!

I always run apt within a sudo -i.

After apt clean/purge/install I got the same error again.

Good guess, that's the problem.  I hardened my system about 5 weeks ago
with some noexecs for several mount-points (including /tmp). After a
"mount -o remount,exec /tmp" the "apt install elpa-folding" run without
problems.

Maybe a "test -x" for the comp-lambda-XXXXXX.eln file with an
appropriate error message before the compilation attempt would be a good
mitigation for this? (probably somewhere in emacsen-common?)

Your 1st guess was bullseye.  :-)

Should I do some additional search why the environment variable
EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION (t) is not honoured?
(If yes, what should I check?)

Best regards, Thomas

Hi Thomas!

I'm sorry for the long delay; it happened because I long ago developed a
habit of drafting replies but then forgetting to send them.

Thomas Dorner <debian-bugs@th-dorner.de> writes:

I also have a hardened server that I was previously use Debian Emacs on
as a normal user; however, Emacs has been unusable with noxec /tmp or
/home ever since we enabled native compilation in the Debian package.

I'm still confused by the fact that native compilation is occurring
during the installation of Debian packages, and that seems wrong to
me...this wouldn't be specific to your system, by the way.  There's been
a bit of churn since you filed his bug, and I wonder if this still
occurs?  Native compilation during package install would be the
actionable bug, in a Debian context.

A simple deduction :)

When I discussed this with the team during the bookworm development
cycle, the consensus seemed to be that upstream assumes that GNU Emacs
will never be run with /home or /tmp mounted noexec.  There's also a
compounding factor that upstream is unable to (or refuses) to support an
Emacs where native compilation is enabled during build time, but
disabled at run time (either by an environment variable or by a user's
emacs.el config).  I'm guessing that native compilation during package
installation is also cause by upstream assumptions, and I wonder if we
just throw away those files?  That seems strange to me, because if we're
burning the CPU cycles/energy/carbon to generate those files, then it
seems like we ought to retain them.  If this is still happening than I
hope we can do better for forky.

Your signature has a cool effect!  How did you achieve this?  It
displays a different font in notmuch vs a web browser.  In my browser
it's an informal slanted pseudo-cursive that looks like it might be a
Google simplified interpretation of Sütterlin, and in notmuch it's
écriture ronde (what I learned) with disconnected letters.  I'm thankful
it didn't render in Kurrent!

Cheers,
Nicholas