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: > After apt clean/purge/install I got the same error again. > >> /\ 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. > > 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. 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. > 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?) 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. >> Looking forward to your findings! > > Your 1st guess was bullseye. :-) A simple deduction :) > 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?) 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. > Best regards, Thomas > -- > 𝓣𝓱𝓸𝓶𝓪𝓼 𝓓𝓸𝓻𝓷𝓮𝓻 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
Attachment:
signature.asc
Description: PGP signature