GNU bug report logs - #49271
28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location

Previous Next

Package: emacs;

Reported by: Jim Myhrberg <contact <at> jimeh.me>

Date: Tue, 29 Jun 2021 11:59:02 UTC

Severity: normal

Found in version 28.0.50

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


Message #50 received at 49271 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Jim Myhrberg <contact <at> jimeh.me>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 49271 <at> debbugs.gnu.org
Subject: Re: bug#49271: 28.0.50: native-comp: Signing macOS self-contained
 .app bundle fails due to new *.eln location
Date: Thu, 1 Jul 2021 21:13:57 +0100
On Thu, Jul 01, 2021 at 03:53:13PM +0100, Jim Myhrberg wrote:
> I've successfully built, signed and notarized a full AoT build with
> this patch. I also applied the patch from bug#49270 to ensure *.eln
> files are located correctly within the bundle.
> 
> Everything is working as expected, and in fact, codesign even
> automatically finds and signs all *.eln files within
> Contents/Frameworks when signing the app bundle itself, so I no
> longer need to individually sign each *.eln file before signing the
> whole app bundle :)

I'm curious what you're actually doing. We have some code that runs on
ARM based Macs only that does this

    codesign -s - -f $@.tmp

where I think $@.tmp is... something... executable?

I'm wondering if we should just install everything into the app bundle
and sign the whole damn thing.

I don't really understand this whole codesigning thing. It seems to
make no difference here, but I'm not trying to run the app on another
Mac or on an ARM Mac, so I think it's normal that I shouldn't see any
difference.

-- 
Alan Third




This bug report was last modified 3 years and 325 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.