fricas is now available in homebrew; call for testers

[Qian Yun]

FriCAS was distributed on macOS via CI-built unsigned dmg
files. It's getting more and more difficult to install
unsigned dmg on recent macOS releases, especially on ARM
chips, I presume.

FriCAS is essentially a command line utility plus the
HyperDoc and graphics components, which requires X11,
which is increasingly rarely installed on recent macOS
I presume. So I believe homebrew should be the perfect
way to distribute FriCAS on macOS.

I took some effort to add fricas to homebrew:
https://github.com/Homebrew/homebrew-core/pull/205760

Since I don't have macOS available right now, especially macOS
on ARM chips, I'm asking for macOS users to test fricas
installed from homebrew.

You can report the following information:
1. OS version and CPU model (amr64 or amd64)
2. whether fricas get installed successfully
3. whether fricas runs successfully
4. If you have X11 server installed, report whether
HyperDoc and graphics works properly

If fricas via homebrew works successfully, I'll use this
as the distribution method instead of the unsigned dmg
method for future release. (But unsigned dmg will still
be available in CI artifices.)

- Qian

[Dima Pasechnik]

On Tue, Feb 25, 2025 at 9:24 PM Qian Yun <oldk...@gmail.com> wrote:
>
> FriCAS was distributed on macOS via CI-built unsigned dmg
> files. It's getting more and more difficult to install
> unsigned dmg on recent macOS releases, especially on ARM
> chips, I presume.
>
> FriCAS is essentially a command line utility plus the
> HyperDoc and graphics components, which requires X11,
> which is increasingly rarely installed on recent macOS
> I presume. So I believe homebrew should be the perfect
> way to distribute FriCAS on macOS.
>
> I took some effort to add fricas to homebrew:
> https://github.com/Homebrew/homebrew-core/pull/205760
>
> Since I don't have macOS available right now, especially macOS
> on ARM chips, I'm asking for macOS users to test fricas
> installed from homebrew.

just tested your Homebrew fricas as a part of SageMath on an arm64
(M1) machine,
all works great! Good work!
No X11 used.

>
> You can report the following information:
> 1. OS version and CPU model (amr64 or amd64)
> 2. whether fricas get installed successfully
> 3. whether fricas runs successfully
> 4. If you have X11 server installed, report whether
> HyperDoc and graphics works properly
>
> If fricas via homebrew works successfully, I'll use this
> as the distribution method instead of the unsigned dmg
> method for future release. (But unsigned dmg will still
> be available in CI artifices.)
>
> - Qian
>

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/64c94810-127a-4490-87e8-0fe6854e41f7%40gmail.com.

[Qian Yun]

On 2/27/25 1:25 PM, Dima Pasechnik wrote:
>
> just tested your Homebrew fricas as a part of SageMath on an arm64
> (M1) machine,
> all works great! Good work!
> No X11 used.
>

Hi Dima,

Thanks for your report!

I also receive a report from Prof. Dr. Johannes Grabmeier,
which "brew install fricas" does not work out of box,
he saw an error message:

Error: Failed applying an ad-hoc signature to
/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
replacing existing signature
/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
main executable failed strict validation

But this can be workaround by "export HOMEBREW_NO_INSTALL_CLEANUP=1".

Do you see the same message? Or do you already set the variable
HOMEBREW_NO_INSTALL_CLEANUP?


The reason behind this is that SBCL generated executable does not
strictly follow modern Mach-O layout rules, because it is appending
the core file after the SBCL executable.

So a proper solution should be generating a core file and use
"sbcl --core /path/to/core" to load it.

I'll try to add support for this to the build system.

- Qian

[Waldek Hebisch]

On Linux SBCL generated executables does not follow normal ELF
rules, in particular 'strip' breaks them and tools intended to
compare binaries may find false positives. Practical solution
is to block such tools (which I assume HOMEBREW_NO_INSTALL_CLEANUP=1
is doing). Proper solution would wrap core into an object
file and link with SBCL "loader" (IIUC CMU CL folks did this,
but it was not ported to SBCL).

We had code to use wrapper script, but our code is simpler
without it.

--
Waldek Hebisch

[Dima Pasechnik]

Hi,

On 27 February 2025 22:31:14 GMT-06:00, Qian Yun <oldk...@gmail.com> wrote:
>On 2/27/25 1:25 PM, Dima Pasechnik wrote:
>>
>> just tested your Homebrew fricas as a part of SageMath on an arm64
>> (M1) machine,
>> all works great! Good work!
>> No X11 used.
>>
>
>Hi Dima,
>
>Thanks for your report!
>
>I also receive a report from Prof. Dr. Johannes Grabmeier,
>which "brew install fricas" does not work out of box,
>he saw an error message:
>
>Error: Failed applying an ad-hoc signature to
>/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
>/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
>replacing existing signature
>/opt/homebrew/Cellar/fricas/1.3.11/lib/fricas/target/arm-apple-darwin23.6.0/bin/FRICASsys:
>main executable failed strict validation
>

I have never seen this. It might be something particular to Johannes' computer.
I read that it can be fixed by
"xcode-select --install". See
<https://github.com/orgs/Homebrew/discussions/673>

>But this can be workaround by "export HOMEBREW_NO_INSTALL_CLEANUP=1".
>

I fail to see how this is related. AFAIK,
the latter is about old versions of packages.

I guess these are several versions of this program on the machine, and they have different signatures.

>Do you see the same message? Or do you already set the variable
>HOMEBREW_NO_INSTALL_CLEANUP?
>
>
>The reason behind this is that SBCL generated executable does not
>strictly follow modern Mach-O layout rules, because it is appending
>the core file after the SBCL executable.

I doubt your reason. I think my reason is more reasonable, and in fact you don't need to fix anything.

HTH,
Dima

[Qian Yun]

But I do see this kind of message in CI environment:
https://github.com/oldk1331/fricas/actions/runs/13535449113/job/37826335707
(And xcode-select --install does not fix it.)

Johannes did not have this error message because he was using
Homebrew under Rosetta emulation (under /usr/local instead of
/opt/homebrew). After removing the old homebrew and start
fresh, he begins to see this message.
The installed fricas actually works, the exported variable
prevents the deletion of this installation.

Anyway, this is a strange situation right now.

- Qian

[Qian Yun]

On 2/28/25 1:09 PM, Waldek Hebisch wrote:
>
> On Linux SBCL generated executables does not follow normal ELF
> rules, in particular 'strip' breaks them and tools intended to
> compare binaries may find false positives. Practical solution
> is to block such tools (which I assume HOMEBREW_NO_INSTALL_CLEANUP=1

Yes, on macOS the failing step is "codesign", and homebrew
consider the installation has failed and do the uninstall
automatically. The env var prevents the uninstall step.

Only one thread about it on SBCL mail lists:

https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/513947F9-2DFA-4653-BF89-34AC0E4F855B%40gmail.com/#msg37368303

> is doing). Proper solution would wrap core into an object
> file and link with SBCL "loader" (IIUC CMU CL folks did this,
> but it was not ported to SBCL).
>
> We had code to use wrapper script, but our code is simpler
> without it.
>

I guess the wrapper script would be similar to the current
ECL approach? If the patch is not complicated, will you
accept it?

- Qian

[Dima Pasechnik]

On 28 February 2025 00:23:59 GMT-06:00, Qian Yun <oldk...@gmail.com> wrote:
>On 2/28/25 1:09 PM, Waldek Hebisch wrote:
>>
>> On Linux SBCL generated executables does not follow normal ELF
>> rules, in particular 'strip' breaks them and tools intended to
>> compare binaries may find false positives. Practical solution
>> is to block such tools (which I assume HOMEBREW_NO_INSTALL_CLEANUP=1
>
>Yes, on macOS the failing step is "codesign", and homebrew
>consider the installation has failed and do the uninstall
>automatically.

This sounds like a possible Homebrew bug.
Did you try to file a bug report with them?
They are usually quick to respond.

[Qian Yun]

On 2/28/25 2:59 PM, Dima Pasechnik wrote:
>
>
> On 28 February 2025 00:23:59 GMT-06:00, Qian Yun <oldk...@gmail.com> wrote:
>> On 2/28/25 1:09 PM, Waldek Hebisch wrote:
>>>
>>> On Linux SBCL generated executables does not follow normal ELF
>>> rules, in particular 'strip' breaks them and tools intended to
>>> compare binaries may find false positives. Practical solution
>>> is to block such tools (which I assume HOMEBREW_NO_INSTALL_CLEANUP=1
>>
>> Yes, on macOS the failing step is "codesign", and homebrew
>> consider the installation has failed and do the uninstall
>> automatically.
>
> This sounds like a possible Homebrew bug.
> Did you try to file a bug report with them?
> They are usually quick to respond.
>

See my detailed reply at:

https://github.com/Homebrew/homebrew-core/pull/205760#issuecomment-2689683141

Basically, other SBCL executable based programs suffer
the same problem, while SBCL core based programs do not.

This is not a problem for Homebrew, unless they can provide
an option in the formula file that disables the "codesign"
step.

- Qian

[Qian Yun]

On 2/28/25 2:23 PM, Qian Yun wrote:
>>
>> We had code to use wrapper script, but our code is simpler
>> without it.
>>
>
> I guess the wrapper script would be similar to the current
> ECL approach? If the patch is not complicated, will you
> accept it?
>
> - Qian
>

It just came to my mind: the wrapper script approach is also
useful for the free version of Allegro CL and Lispworks,
where you can not dump images.

- Qian

[Dima Pasechnik]

This is still a Homebrew bug (I'd even say a security vulnerability), as
setting HOMEBREW_NO_INSTALL_CLEANUP=1
in effect turns off checking signatures, and it doesn't look like it was meant to do this.

Dima


>
>- Qian
>

[Qian Yun]

On 3/1/25 9:36 AM, Dima Pasechnik wrote:
>
> This is still a Homebrew bug (I'd even say a security vulnerability), as
> setting HOMEBREW_NO_INSTALL_CLEANUP=1
> in effect turns off checking signatures, and it doesn't look like it was meant to do this.
>
> Dima
>

It is not checking signatures, it is adding a self-signed signature
to the binary.

I took a look that FRICASsys has the signature inherited from sbcl.

I could not explain why fricas installs without this error message
on your system.

I also could not explain why fricas runs on system with the error
message -- the signature is from sbcl and will fail to verify.

I find the related bug on SBCL bugtracker:
https://bugs.launchpad.net/sbcl/+bug/1869401

====
You would have to remove ':executable t' from the save-lisp-and-die to
produce a conforming binary.
Basically we cheat by assuming that copying arbitrary bytes to the end
of an executable file just works. There is other tooling that doesn't
like it either, e.g. 'strip'.
====

I'll try this approach first.

- Qian