all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Myhrberg <contact@jimeh.me>
To: 49271@debbugs.gnu.org
Subject: bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location
Date: Tue, 29 Jun 2021 12:58:44 +0100	[thread overview]
Message-ID: <CAGaZ61twxbJATg55cvAgQ8bdFdn-8pFneXj1LBPGb1OaK=Y6+Q@mail.gmail.com> (raw)

Commit 5dd2d50 seems to have moved the native-lisp folder within self-contained
Emacs.app bundles:

- from: "Contents/Resources/native-lisp"
- to:   "Contents/MacOS/lib/emacs/28.0.50/native-lisp"

Unfortunately, Apple's codesign utility blows up with an error if there is any
folder within "Contents/MacOS" (recursively) which contains two dots within its
name. Here is an example of what the error looks like:

    /Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app:
bundle format unrecognized, invalid, or unsuitable
    In subcomponent:
/Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app/Contents/MacOS/lib/emacs/28.0.50

The above error is from this GitHub Actions workflow run:
https://github.com/jimeh/emacs-builds/runs/2923284812?check_suite_focus=true

The same issue happens locally for me too.

I have so far not found a way to make codesign not blow up on such folders, so
for now I've had to workaround the issue in my build script with the following
changes:

- https://github.com/jimeh/build-emacs-for-macos/commit/eeca7b798de236a3ffc1ab04b0f7735a37ce5af4
- https://github.com/jimeh/build-emacs-for-macos/commit/23b8236e0a66fb09810e8422bedf02f7192a53e4

In summary, I rename:

- from: Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-852ecda2
- to:   Emacs.app/Contents/MacOS/lib/emacs/28-0-50/native-lisp/28-0-50-852ecda2

(Note that I had to rename both "28.0.50" and "28.0.50-852ecda2"
folders, as both
trigger the error from codesign.)

I create a symlink from "Contents/native-lisp" to
"Contents/MacOS/lib/emacs/28-0-50/native-lisp".

And finally I patch Emacs.pdmp (Emacs.app/Contents/MacOS/libexec/Emacs.pdmp),
performing the following raw text replacements:

- "lib/emacs/28.0.50/native-lisp/28.0.50-852ecda2/" -->
"lib/emacs/28-0-50/native-lisp/28-0-50-852ecda2/"
- "../native-lisp/28.0.50-852ecda2/" --> "../native-lisp/28-0-50-852ecda2/"

This yields a seemingly actually working Emacs.app bundle, but it re-compiles
all *.eln files in the bundle into the user cache folder. However, there's a
separate bug causing re-compiling which I've reported as bug#49270, so for now I
don't know if my patching would prevent Emacs from dynamically finding existing
*.eln which are not referenced from Emacs.pdmp.

This patching/workaround to get code signing to work feels very hacky and
fragile. It would be great if we could avoid the need for this kind of patch to
be able to codesign the .app bundle.

The way I see it, there's three possible solutions:

- Figure out a way to make Apple's codesign play nice.
- Move the native-lisp folder back to "Contents/Resources/native-lisp", as
  codesign does not complain about folders with two dots in their names within
  the Resources directory.
- Change paths used to store *.eln files within Contents/MacOS so no single
  folder name contains two dots.





             reply	other threads:[~2021-06-29 11:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 11:58 Jim Myhrberg [this message]
2021-06-29 19:18 ` bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location Alan Third
2021-06-30 10:04   ` Jim Myhrberg
2021-06-30 12:20     ` Eli Zaretskii
2021-06-30 12:39       ` Jim Myhrberg
2021-06-30 12:52         ` Alan Third
2021-06-30 13:10           ` Jim Myhrberg
2021-06-30 19:05             ` Alan Third
2021-07-01  7:13               ` Eli Zaretskii
2021-07-01 18:45                 ` Alan Third
2021-07-01 19:03                   ` Eli Zaretskii
2021-07-01 19:56                     ` Alan Third
2021-07-01 14:53               ` Jim Myhrberg
2021-07-01 20:13                 ` Alan Third
2021-07-01 20:43                   ` Jim Myhrberg
2021-07-01 21:16                 ` Alan Third
2021-06-30 12:42       ` Alan Third
2021-06-30 12:51         ` Jim Myhrberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGaZ61twxbJATg55cvAgQ8bdFdn-8pFneXj1LBPGb1OaK=Y6+Q@mail.gmail.com' \
    --to=contact@jimeh.me \
    --cc=49271@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.