Some chapel scripts look for python3 on PATH. Since `python@3.10`
is not linked, these scripts have been using system python3.8 on
macOS 10.15+ and are now failing on Linux.
Also add a workaround for Homebrew 11-arm64 runner, which outputs
unwanted objc warnings that cause issues for checkChplInstall.
Closes#103218.
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Synergy is a free and open source program for sharing a mouse and keyboard
among multiple computers. It supports 64-bit Intel Mac, 64-bit ARM Mac,
64-bit GNU/Linux, and other platforms.
Synergy was previously available in brew as a cask named `synergy`. That
cask installed binaries published by Symless, the corporate sponsor of
Synergy. However, at some point in the last couple months, Symless decided
to start charging money for access to the binaries on its website. As part
of this change, the Symless binaries were placed behind an authentication
webpage. As a result, the `synergy` cask was removed from brew:
https://github.com/Homebrew/homebrew-cask/commit/0037f2409
However, even though Symless no longer publishes binaries, Synergy remains
fully free and open source software, licensed under GPL version 2 (with an
exception allowing "compiling, linking, and/or using OpenSSL"). As a result,
nothing stops us from building our own binaries from the source code. This
new `synergy-core` formula does exactly that: it builds Synergy from source
and installs it.
This formula supports 64-bit Intel Mac, 64-bit ARM Mac, and 64-bit GNU/Linux.
I have tested the formula on all three platforms. (For GNU/Linux testing, I
used Fedora 35, although that probably doesn't matter.)
This formula sets up a `synergy-core` daemon that can be run and managed
using `brew services`. This daemon is currently how I recommend running
the binaries built by this formula.
***
The `synergy-core` project is distributed under the GPL-2.0 license with an
exception that grants additional rights to the user. The project's LICENSE
file reads as follows:
This program is released under the GPL with the additional exemption
that compiling, linking, and/or using OpenSSL is allowed.
This preamble is followed by the text of the GPL-2.0.
This is a free software license but it cannot be represented with the `brew`
license statement, so the formula uses `license :cannot_represent`.
Unfortunately, the GitHub Licenses API incorrectly states that `synergy-core`
is licensed strictly under the GPL-2.0. So we need to add `synergy-core` to
audit_exceptions/permitted_formula_license_mismatches.json
to avoid `brew audit` objecting that the license specified in the
`license` statement is different from the license returned by the
GitHub Licenses API.
Closes#100067.
Co-authored-by: Sean Molenaar <SMillerDev@users.noreply.github.com>
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Closes#99176.
Signed-off-by: Michael Cho <20700669+cho-m@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Closes#94807.
Signed-off-by: Michael Cho <20700669+cho-m@users.noreply.github.com>
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
The conflict comes from the version of Python used by `node`, but this
conflict is not a problem. (In fact, Node uses the first `python3` that
a user has in their `PATH` on macOS with no problems.)
`soci` does not use Libtool, and so is not subject to the usual macOS
version misdetection bug.
Closes#94941.
Signed-off-by: Sean Molenaar <1484494+SMillerDev@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
This is needed for #94505. The conflict comes from `freedink` depending
on `python@3.10` and `python@3.9` through `cxxtest` and `glib`
respectively.
`cxxtest` is installed into a virtualenv in `libexec`, so it's unlikely
that `freedink` actually makes use of anything there since it ships no
Python code itself.
An alternative to this is to migrate `glib` to `python@3.10`, which will
take quite a while (see #87277), or migrate `cxxtest` back to
`python@3.9`, which is unnecessary.
I've tested `freedink` locally and it seems to work fine despite the
mixed recursive dependency.
See also #65831.
Closes#94505.
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
The `-flat_namespace` flag comes from OCaml. This should go away when
Ocaml is updated in #87856.
Closes#92247.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
To dodge the versioned dependency conflict audit, I've added `coind3d`,
`gjs`, `pyside` and `pyside@2` to the allowlist. It's very unlikely that
these formulae use LLVM's Python bindings. LLVM is keg-only, and we
don't modify `PYTHONPATH`, so these formulae shouldn't even be able to
find LLVM's Python bindings.
However, just in case, I've also installed LLVM's Python bindings for
multiple versions of Python3. (This doesn't include LLDB, which has
linkage with the Python framework, which ties it to a specific Python
version.)
While we're here:
- remove duplication from the installed Xcode toolchain
- fix some version references so that they work for HEAD installs too
We clean up the duplication by installing the Xcode toolchain manually.
Closes#87483.
The `-flat_namespace` flag is inherited from `open-mpi`. See
`ompi-fort.pc`, which contains:
Cflags: -I${includedir} -Wl,-flat_namespace -Wl,-commons,use_dylibs -I${libdir}
This is needed for bottling on Monterey.
The `-flat_namespace` flag comes from OCaml, and should go away when the
OCaml bottles are rebuilt.
Closes#89870.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
We need to add Watchman to the dependency conflict allowlist or else the
audit will complain about the conflicting Python 3.9 from Rust, which
shouldn't matter.
Closes#89256.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Branch Vincent
Michka Popoff
Michael Cho
danielnachun
Luca Chen
Cathy J. Fitzpatrick
BrewTestBot
Francois-Xavier Coudert
Tristan Naumann
Rui Chen
Thierry Moisan
Jonas Greitemann
Padraic Fanning
Carlo Cabrera
Dzmitry Neviadomski