Hi Ben
Thanks for the quick responses particularly on the weekend before your vacation.
you wrote:
What happens
if you try to install to do something like (in the extracted binary distribution),
$ ./configure --prefix=`pwd`/tmp
$ make install # this will fail
$ xattr -rc .
$ make install # perhaps this will finish successfully?
# tmp/bin/ghc --version # GHC should be usable
success on both my machines using a slightly modified version of your suggestion above for 21506:
./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical
xattr -rc . # seems to be necessary also
sudo make install # seems to works , output ends with "recache"
./tmp/bin/ghc --version # success , although admittedly the smallest smoke test possible
You wrote:
>
Ultimately I think we may just need to bite the bullet and start
properly notarising/codesigning releases (resolving #17418). At this point we have
spent more time trying to avoid the notarisation requirement than
it would likely take to satisfy it. Unfortunately, this will require
that I find an Apple device somewhere which may take a few weeks.
I'm afraid I am on holiday next week but I would quite grateful if we
could arrange for a chat after I return such that we can debug this in
realtime.
Sure, we can chat when you return from your vacation.
Not sure if it is worth trying to fix the release on the basis of what I write above. My opinion is: it is if we can get reports of at least one other person having this issue. I am fine with not doing this for 9.4.1
I agree that we should raise the priority of "notarising/codesigning releases (resolving #17418)". My opinion is that it is not worth delaying 9.4.1 for this.
Have a great vacation.
Cheers
George
George Colpitts <george.colpitts@gmail.com> writes:
> +Kazu Yamamoto <kazu@iij.ad.jp>
>
> Hi Ben
>
> My 2 machines also have:
>
> $ spctl --status
> assessments enabled
>
Hmm, interesting. Then I am truly perplexed.
> Speculations:
>
> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
> is created after xattr -rc . was run so it doesn't have the necessary
> attributes. Is it possible that ghc developers and/or the test machines
> have this file on another of the paths in the error message and that is why
> it works for them?
>
I'm not sure where this would be but at this point anything is possible. What happens
if you try to install to do something like (in the extracted binary distribution),
$ ./configure --prefix=`pwd`/tmp
$ make install # this will fail
$ xattr -rc .
$ make install # perhaps this will finish successfully?
# tmp/bin/ghc --version # GHC should be usable
> I hope I didn't offend you by asking if the fix had been tested; I assume
> it had been but I thought it was important to rule that out.
>
Not to worry; it's a very reasonable question to ask given the circumstances.
> More than happy to test. I really appreciate all the work you and others
> have put into GHC !
>
Ultimately I think we may just need to bite the bullet and start
properly notarising/codesigning releases (resolving #17418). At this point we have
spent more time trying to avoid the notarisation requirement than
it would likely take to satisfy it. Unfortunately, this will require
that I find an Apple device somewhere which may take a few weeks.
I'm afraid I am on holiday next week but I would quite grateful if we
could arrange for a chat after I return such that we can debug this in
realtime.
Cheers,
- Ben