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>
clang-format 12+ is buggy, and 8 is too old.
Closes#88098.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Neither project actually sets the `-flat_namespace` flag themselves.
Instead, this is inherited from `open-mpi`:
```
❯ pkg-config ompi-fort --cflags
-Wl,-flat_namespace -Wl,-commons,use_dylibs -I/usr/local/Cellar/open-mpi/4.1.1_2/include -I/usr/local/Cellar/open-mpi/4.1.1_2/lib
```
This is needed for bottling on Monterey. The library built with the
`-flat_namespace` flag is built that way on Catalina too.
This seems intentional, as most of the other libraries have a two-level
namespace.
I've seen more than a handful of PRs that fail the audit requesting that
a formula do `uses_from_macos` instead of `depends_on` for `llvm`, but
the audit was wrong in every one of those instances. The `llvm` formula
includes much more than what comes with macOS.
Closes#84391.
Signed-off-by: rui <rui@chenrui.dev>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
- Repo was moved from github.com/AkihiroSuda/lima to github.com/lima-vm/lima
- `mismatched_binary_allowlist.json` is added for allowing installation of
`lima-guestagent.Linux-<Non native arch>` binary.
Closes#82723.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
Per the discussion in #81666:
- build `term-size` binary from source
- add `ask-cli` to universal binary allowlist
Also, add `ask-cli` to `binary_bootstrap_formula_urls_allowlist.json` as
the resouce URL is being mistaken for a binary URL.
Closes#81644.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
See #81666.
Closes#81623.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
See #81666.
Closes#81621.
Signed-off-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Signed-off-by: BrewTestBot <1589480+BrewTestBot@users.noreply.github.com>
We copy `JavaNativeFoundation.framework` out of the Xcode SDK, so it's
no surprise that we find a universal binary in the bottle.
I'll work on adding formula methods that will allow us to extract the
arm64 slice in an `install` method.
The LLVM formulae build universal binaries for compiler-rt. This is why
these formulae use `ENV.permit_arch_flags`. Infer vendors its own clang,
and so also has its own compiler-rt.
`babel` and `contentful-cli` both install the npm package `fsevents`,
which installs a universal native module `fsevents.node`. I suggest
adding them to the allowlist for now so we have a list that keeps track
of them. (It would be nice if JSON files allowed comments though.)
I have changes in mind for `brew` that will allow us to easily extract
the native slices from these binaries, but I'd like to see it needed by
more formulae before we add it to `brew`. This list should help us keep
track of the number of formulae that would need this.
This commit unblocks #81556 and #81582.
See Homebrew/brew#11737 for context.
* linux-headers@4.15: new formula
* linux-headers: rename to linux-headers@4.4
* linux-headers@4.4: renamed from linux-headers
* linux-headers: make alias to linux-headers@4.4
* formula_renames.json: rename linux-headers to linux-headers@4.4
* versioned_keg_only_allowlist: add linux-headers@4.4
* glibc: use linux-headers@4.4
* strace: use linux-headers@4.4